This chapter describes considerations when integrating TOMCAT.
JDK environment when using TOMCAT
When processing the preparestatement using DBCP, it is recommended to use in JDK(JRE) 1.6 or higher environment to change testOnBorrow (default: true) poolPrepareStatements (default: false) setting to improve performance.
Symptoms of the problem
Tomcat log (version 6)
If it is normal,
How to check
Reference: http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html
Recommended Tomcat settings
| Environment 1 | Environment 2 | Environment 3 |
|---|---|---|---|
JDK Ver | 1.5 | 1.6 | 1.6 |
poolPrepareStatements | Only FALSE recommended (Default) | True/False | True/False |
Result | testOnBorrow=False, Upgrade to JRE or JDK1.6 recommended | Recommended | Recommended |
testOnBorrow | Only TRUE recommend (Default) | True/False | True/False |
Tomcat Ver | 6 (dbcp ver 1.3) | 6 (dbcp ver 1.3) | 7 (dbcp ver 1.4) |
- testOnBorrow
+ When getting a connection from the connection pool, the connection is validated
+ The default value is false, and the default value is generally used. If set to true, validationQuery is executed every time, so a slight performance decrease is expected. - poolpreparestatement
+ Statement pooling is maintained for each connection in DBCP, so the application server (App) keeps the information compiled for the query. After that, it is possible to improve performance by repeating only the execute step without preparing the same query.
Return of used resource
Connection, Statement, and ResultSet allocated by the program must be explicitly closed after use. If it is not closed, resources are continuously allocated during the life cycle of the variable that declared the above resource, which results in unnecessary resource consumption.
If the connection is not closed, the connection will not be returned to the pool, so it will be unable to use it elsewhere.
Statement information is allocated and remained in memory not only on the application but also on the DB server while the session is maintained. Therefore, if the statement and the connection are not closed, this could be a problem for unnecessary resources are continuously allocated in the application, but the Query_Prepare memory area of the DB server also increases.
If the above resources are not explicitly closed, they are allocated in memory during the life cycle of the variable that declares the resource. If the life cycle ends, the resource is no longer referenced, so the JVM (Java Virtual Machine) and GC (Garbage Collector) will later release the resource. However, GC is generally the lowest priority thread. Therefore, it is difficult to predict when the GC releases the resource. In other words, it can not be released immediately because the life cycle of the variable is no longer referenced in the application, and the DB server keeps the information about the resource unless the GC releases it.
Therefore, it is recommended to close the used resource explicitly.
Remove abandoned connection
There is one problem when processing a connection using DBCP, which means close ResultSet, Statement, and Connection must be explicitly closed in the web application. If the web application fails to close these resources, the resources cannot be reused later. This sita is called a connection pool leak, and if the connection pool leak persists, all available connections will eventually disappear. To prevent this problem, DBCP provides a method for recovering and logging a connection that has been abandoned due to a problem. The following property can be set.