Using the Tomcat 7 JDBC Connection Pool in Production


News: Using the Tomcat 7 JDBC Connection Pool in Production


    One of the new features with Apache Tomcat 7 is the JDBC Connection Pool which is offered as a replacement to the commons-dbcp connection pool that is tailored to better serve highly concurrent (multi-core / multi-cpu) environments.

    Getting started with the JDBC Connection Pool is very simple, meaning the most existing commons-dbcp users can switch to the JDBC Connection Pool by simply adding the following property to their configuration: factory=”org.apache.tomcat.jdbc.pool.DataSourceFactory”. From there, your knowledge of commons-dbcp configuration options should help significantly as virtually all of the config options are supported by the JDBC Connection Pool. 

    Support for Connection Validation Interval

    The very principal of connection pools are that they set up persistent, shared connections from your application to your database. These connections can get lost occasionally, and yet remain available to the application. Validation queries are the standard way to check that the connection is still good.  Tomcat 7’s JDBC Connection Pool offers a new parameter called validationInterval that lets you determine how frequently a given validation query is executed, giving you greater control over the performance trade-offs while ensuring your application against stale connections.  

    VMware SpringSource Software Support Engineer, Daniel Mikusa explains the tradeoffs in his article on today:

    "For example, a value of 60 seconds means that a validation query only needs to run once every 60 seconds for each connection.  However, that also means that once a connection is validated it will not be revalidated for another 60 seconds.  If a database connection were to be lost one second after it was validated then there would be a period of 59 seconds where the connection would still be considered valid by the connection pool.  If a connection were to be borrowed while in this state, use of the connection would fail and the application would get a connection error."

    JDBC Interceptors

    The JDBC Connection Pool allows a concept of a JDBC Interceptor which injects functionality independent of your application to your connection pool with simple configuration. Enabling an interceptor is easy; add the jdbcInterceptors property to your connection pool configuration and specify a semi-colon separated list containing the names of the interceptors to be used. Example: jdbcInterceptors=”ConnectionState;StatementFinalizer”. If you are adding a custom interceptor, you would reference the full class name. Example: com.mycompany.interceptors.MyCustomInterceptor. 

    Tomcat 7 ships with a few interceptors, which Mikusa explains in more depth in his [article]. One particularly interesting interceptor is the ResetAbandonedTimer with the removeAbandoned property. Enabled together, it helps protect legitimate long running queries from being interrupted by an aggressive move to reclaim connections. Every time a legitimate SQL operation is made, the timer is reset and gives the connection the full timeout length before attempting to reclaim the connection. 

    Mikusa concludes the article strongly suggesting all users of the commons-dbcp try to switch their application to the more performance friendly JDBC Connection Pool. The full article can be read here.









    Threaded Messages (1)

  2. max connections[ Go to top ]

    Be sure to check for values of max and min number of connections that the connection pool will maintain. All applications will have value for these parameters as per requirement and a wrong value can hamper the performance.