DataSource or ConnectionPoolDataSource for Application Server JDBC resources

Vincent_Fazio_2890 0
Viewed 21323

When creating JNDI JDBC connection pools in an application server, I always specified the type as javax.sql.ConnectionPoolDataSource. I never really gave it too much thought as it always seemed natural to prefer pooled connections over non-pooled.

However, in looking at some examples (specifically for Tomcat) I noticed that they specify javax.sql.DataSource. Further, it seems there are settings for maxIdle and maxWait giving the impression that these connections are pooled as well. Glassfish also allows these parameters regardless of the type of data source selected.

  • Are javax.sql.DataSource pooled in an application server (or servlet container)?
  • What (if any) advantages are there for choosing javax.sql.ConnectionPoolDataSource over javax.sql.DataSource (or vice versa)?
application-server connection-pooling configuration database java
3 Answers

As for the Java docs it contains this:

DataSource Java 7 API

The DataSource interface is implemented by a driver vendor. There are three types of implementations:

Basic implementation -- produces a standard Connection object

Connection pooling implementation -- produces a Connection object that will automatically participate in connection pooling. This implementation works with a middle-tier connection pooling manager.

Distributed transaction implementation -- produces a Connection object that may be used for distributed transactions and almost always participates in connection pooling. This implementation works with a middle-tier transaction manager and almost always with a connection pooling manager.

PooledConnection Java 7 API

An application programmer does not use the PooledConnection interface directly; rather, it is used by a middle tier infrastructure that manages the pooling of connections.

When an application calls the method DataSource.getConnection, it gets back a Connection object. If connection pooling is being done, that Connection object is actually a handle to a PooledConnection object, which is a physical connection.

The connection pool manager, typically the application server, maintains a pool of PooledConnection objects ....

So in the end you just use DataSource and Connection classes and never PooledConnection / ConnectionPoolDataSource, if you are a happy and normal programmer.

If are implementing an Application Server that's another story...

user_12110950
Related