Tomcat jdbc-pool

Blog : Apache Tomcat 7.0.19 Released

posted by Stacey Schneider on July 19, 2011 09:23 AM

Announced this morning by the Apache Tomcat team:


The Apache Tomcat team announces the immediate availability of Apache Tomcat 7.0.19

Apache Tomcat 7.0.19 includes security fixes, bug fixes and the following new features compared to version 7.0.16:

  • JSP recompilation is now triggered by any change (backwards as well as forwards) in the last modified time of the JSP or any of its dependencies
  • Support for installing multiple instances with the Windows Installer
  • Include jdbc-pool (an alternative database connection pool)

Please refer to the change log for the complete list of changes:

The following known issues in 7.0.19 are noteworthy:

  • The AJP NIO connector does not use persistent connections. To workaround this, use a large value for connectionTimeout
  • There is a typo in the list of JARs to skip in Apply to fix it

Note that this version has 4 zip binaries: a generic one and three bundled with Tomcat native binaries for Windows operating systems running on different CPU architectures.


Migration guide from Apache Tomcat 5.5.x and 6.0.x:

Thank you,

-- The Apache Tomcat Team

Read More



Developers, Executives | Tomcat 7, Tomcat jdbc-pool

Blog : Building extensions to jdbc-pool

posted by fhanik on April 19, 2010 06:08 AM

In our previous blog posts, we gave a short introduction to a new module,  jdbc-pool, currently being development inside of Apache Tomcat's subversion development branch as a high concurrency alternative to connection pooling. We also covered jdbc-pool performance and how to cconfigure jdbc-pool for optimal performance.

In this article we'll dig a bit deeper under the covers and take a look at how to build extensions to the jdbc-pool. To do this, we will build a prepared statement cache for the jdbc-pool using the interceptors as a base.

A note of caution

Personally, I don't believe that connection pools should perform any level of statement caching. Here are a few reasons why:

  • Statements represent resources on the database back end. Hence this cache leads to increased resources usage.
  • Statement caches belong on the database, in worst case in the JDBC driver. But not in a connection pool.
  • The overhead of preparing a statement can be cached and optimized on the database, rather than at a much higher level, since the overhead mainly is related to the parsing of the query.
  • Statements have to be cached on a per connection basis, not making it an optimal cache for a connection pool
  • There is an API to allow the underlying driver/database to handle it using the setPoolable call.
    If you take a look at a number of databases, these databases already have facilities for caching and optimizing statements, take DB2 dynamic statements as a simple example.

Setting up the interceptor

Most of the extensions in jdbc-pool can be accomplished using the JDBC interceptor base class. The interceptors all extend the invocation handler interface.

This means, that any method invocations on the Connection interface will pass through the

Object invoke(Object proxy, Method method, Object[] args) throws Throwable;

method. So if the user is calling javax.sql.PooledConnection.getConnection method we could implement that as:

1:  public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
2:    if (method.getDeclaringClass().equals(PooledConnection.class) &&
3:        compare(GETCONNECTION_VAL,method) { 
4:        return connection.getConnection();
5:    } else {
6:        return super.invoke(proxy,method,args);
7:    }
8:  }
  • Line 2 - We check that the interface that is being called is the javax.sql.PooledConnection.getConnection class
  • Line 3 - We check that the method being called is getConnection
  • Line 4 - We return the underlying connection
  • Line 6 - If the above conditions have not been met, pass on the request to the next interceptor.

Read More



Developers, Operations | connection pool, Tomcat 7, Tomcat Admin

Blog : Configuring jdbc-pool for high-concurrency

posted by fhanik on April 1, 2010 03:19 PM

In this article we will focus on configuration of the high-concurrency connection pool. For ease of migration for Tomcat users, the configuration has been written to mimic that of Commons DBCP.

The documentation of jdbc-pool covers all the attributes. Please note that these attributes are also available as direct setters on the org.apache.tomcat.jdbc.pool.DataSource bean if you're using a dependency injection framework. So in this article we will focus on use cases, and different configurations for Tomcat.

Simple Connection Pool for MySQL

<Resource type="javax.sql.DataSource"

The first thing we notice is the factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" attribute.
When Tomcat reads the type="javax.sql.DataSource" it will automatically configure its repackaged DBCP, unless you specify a different factory. The factory object is what creates and configures the connection pool itself.

There are two ways to configure Resource elements in Apache Tomcat.

Read More



Developers, Operations | connection pool, DBCP, high-concurrency

Blog : Understanding the jdbc-pool performance improvements

posted by fhanik on March 24, 2010 12:12 PM

In our previous article we gave a short introduction to a new module,  jdbc-pool, currently being development inside of Apache Tomcat's subversion development branch as a high concurrency alternative to connection pooling.

One of the main reasons this module was started was performance. In this article we will show you how to benchmark your tests and also share some performance numbers on the high-concurrency connection pool.

You can run these tests yourself against an in-memory database. Assuming you have Java 6, Ant and SVN installed simply follow these steps:

svn co
cd jdbc-pool
ant test

In our test runs we used a local MySQL database on a Solaris machine. While there is some overhead in creating a connection to MySQL, in our tests, this is a one-time affair, as we are testing pooled connections.

Read More



Developers, Operations | connection pool, DBCP, high concurrency

Syndicate content