1. Tomcat official website Documentation Reference http://tomcat.apache.org/tomcat-6.0-doc/jndi-datasource-examples-howto.html
2. test:
Add the following code to Tomcat context. xml: Generally, it is in the \ conf \ directory of the tomcat installation directory.
<Resource name="jdbc/myoracle" auth="Container" type="javax.sql.DataSource" driverClassName="oracle.jdbc.driver.OracleDriver" url="jdbc:oracle:thin:@192.168.1.178:1521:sbin" username="CIVILIZATION" password="CIVILIZATION" maxActive="20" maxIdle="10" maxWait="-1"/>
Add the following code to the file WEB-INF/Web. XML in your own project file:
<resource-ref><description>Oracle Datasource example</description><res-ref-name>jdbc/myoracle</res-ref-name><res-type>javax.sql.DataSource</res-type><res-auth>Container</res-auth></resource-ref>
Code:
/*** Use the data source method to obtain the connection * @ return */public connection getconnetion () {connection con = NULL; try {context initcontext = new initialcontext (); context envcontext = (context) initcontext. lookup ("Java:/COMP/ENV"); datasource DS = (datasource) envcontext. lookup ("JDBC/myoracle"); con = Ds. getconnection ();} catch (exception e) {// todo auto-generated catch blocke. printstacktrace ();} return con ;}
3. other operations are the same as normal data connections. If you directly write the main () function in dbmanger during the test, an error is returned, we need to test it on the servlet or JSP page.
4. solutions to common problems
4.1 random Connection closed exceptions
These can occur when one request gets a DB connection from the connection pool and closes it twice. When using a connection pool, closing the connection just returns it to the pool for reuse by another request,
It doesn't close the connection. And Tomcat uses multiple threads to handle concurrent requests. Here is an example of the sequence of events which cocould cause this error in Tomcat:
Request 1 running in Thread 1 gets a db connection. Request 1 closes the db connection. The JVM switches the running thread to Thread 2 Request 2 running in Thread 2 gets a db connection (the same db connection just closed by Request 1). The JVM switches the running thread back to Thread 1 Request 1 closes the db connection a second time in a finally block. The JVM switches the running thread back to Thread 2 Request 2 Thread 2 tries to use the db connection but fails because Request 1 closed it.
Here is an example of properly written code to use a database connection obtained from a connection pool:
Connection conn = null; Statement stmt = null; // Or PreparedStatement if needed ResultSet rs = null; try { conn = ... get connection from connection pool ... stmt = conn.createStatement("select ..."); rs = stmt.executeQuery(); ... iterate through the result set ... rs.close(); rs = null; stmt.close(); stmt = null; conn.close(); // Return to connection pool conn = null; // Make sure we don't close it twice } catch (SQLException e) { ... deal with errors ... } finally { // Always make sure result sets and statements are closed, // and the connection is returned to the pool if (rs != null) { try { rs.close(); } catch (SQLException e) { ; } rs = null; } if (stmt != null) { try { stmt.close(); } catch (SQLException e) { ; } stmt = null; } if (conn != null) { try { conn.close(); } catch (SQLException e) { ; } conn = null; } }
4.2 intermittent database connection failures
Tomcat runs within a JVM. the JVM periodically performs garbage collection (GC) to remove Java objects which are no longer being used. when the JVM performs GC execution of code within Tomcat freezes. if the maximum
Time configured for establishment of a database connection is less than the amount of time garbage collection took you can get a database connection failure.
To collect data on how long garbage collection is taking Add-verbose:gc
Argument to yourCATALINA_OPTS
Environment variable when starting tomcat. When verbose GC is enabled your$CATALINA_BASE/logs/catalina.out
Log
File will include data for every garbage collection including how long it took.
When your JVM is tuned correctly 99% of the time a GC will take less than one second. the remainder will only take a few seconds. rarely, if ever shoshould a GC take more than 10 seconds.
Make sure that the DB connection timeout is set to 10-15 seconds. For the DBCP you set this using the ParametermaxWait
.