4

I have been somewhat away from Java EE for a while, but I have a basic idea of all this stuff.

I am reading the JTDS docs here:

http://jtds.sourceforge.net/features.html

It says it provides statement pooling, and connection pooling, but does not provide a connection pool implementation.

  1. Provided that the JTDS driver itself provides connection pooling, then why do I need a connection pool (like DBCP) on top it?
  2. In other words, what is the difference between that connection pooling provided by JTDS, and a full-blown connection pool implementation (in the sense of this JTDS documentation page) on top of it?
  3. Also, what's the difference between statement and connection pooling (as mentioned there on this JTDS doc page)?

Feel free to add more details to your answer
(whatever you find important; things I didn't ask explicitly about)
as I am quite confused with this.

Tiny
  • 27,221
  • 105
  • 339
  • 599
peter.petrov
  • 38,363
  • 16
  • 94
  • 159
  • 1
    It looks like "Statement Pooling" is a typo and should be "Statement cache" which is a pretty need feature: the driver will re-use prepared statements for a connection when the application fires the same queries (e.g. repeating queries like "select * from users where userid=?"). That can save a lot of (IO/network) time and a connection pool implementation like [HikariCP](https://github.com/brettwooldridge/HikariCP) assumes a JDBC driver has this feature (HikariCP has choosen not to implement a statement cache feature). – vanOekel Jan 16 '15 at 00:12

1 Answers1

6

As far as I can tell from the API documentation, they mean that jTDS provides a javax.sql.PooledConnection and a javax.sql.ConnectionPoolDataSource implementation. These classes are to be used by a connection pool of - for example - a Java EE application server, and are not a connection pool itself.

The ConnectionPoolDataSource creates PooledConnection objects, or in other words it is the data source for a connection pool. The PooledConnection is the handle for the physical connection, and is held within the connection pool. When a user asks for a connection from the pool, the connection pool moves the PooledConnection from the 'available' to the 'in use' list, and obtains a logical java.sql.Connection from the PooledConnection. This logical connection is what is handed to the user.

The PooledConnection can be use by the connection pool to monitor the logical connection. For example to return the PooledConnection to 'available' when close() is called, or forcibly revoke and invalidate the logical connection (eg if it is in use too long).

So jTDS does not have a connection pool implementation itself, but it has the support for a connection pool. It is unfortunate that the wording in the JDBC specification is so confusing.

I have a more detailed answer on this subject on a similar question.

Community
  • 1
  • 1
Mark Rotteveel
  • 100,966
  • 191
  • 140
  • 197