Java Feature — JDBC 4.0

It's been over three years since the JDBC Expert Group held its first meeting to gather requirements, requests, and pipe dreams for the JDBC 4.0 specification. In that meeting, we discussed a wide variety of topics, including performance enhancements, clarifications on the existing JDBC 3.0 specification, and Ease of Development features. Unbelievably, everything but the kitchen sink ended up making it into the release. In this article, we'll look at several key features that made the enhancement list for JDBC 4.0, and we'll discuss why those features are important.

Reader Feedback: Page 1 of 1

Rob Bygrave commented on 17 Nov 2006

Nice article and some good points.

setClientInfo()
---------------
Yes, these look useful. It should be noted that on the java client side you can determine the calling code/method by looking at the stack trace and this can be done automatically by the pool. This maybe available to diagnose problems for some.

Connection.isValid()
--------------------
I guess some pools are as dire as the 'Typical' one you describe but maybe isValid is less useful than it appears.

Specifically I would have hoped most pools would use a simple light query (e.g. select count(*) from dual) to test connections to make sure they are valid. Certainly I expect existing pools to detect dead connections and remove them individually (rather than flush the entire pool).

Perhaps isValid is better in that it is more standard and perhaps more performant than executing a simple query - but perhaps a query is better in that it is exercising the database as well. This after all, only has to be done on Connections that need to be checked for validity (when they have errored) or occassionally to check for Database down.

Q: Can you use isValid to check for the Database down event? Its not clear to me that this is included as a intended use of isValid? If isValid doesn't do this then are we not better using a simple light query so that we are also detecting database down events?

JDBC statement pooling
----------------------
Its nice to standardise the API to tune the statement pooling but this is of course possible right now. Pools can right now use a LRU PreparedStatement cache and provide tuning for it. Being LRU then the frequently used statements stay in the cache so your statement thats executed twice should not kick out the one executed 100 times.

RowId
-----
I am interested in JDBC4's RowId but I'm looking for more information on it. Specifically on what its intended use is? The example in the Spec 15.10.3 why would I use RowId instead of just binding the ID value? I have to know its the ID by the DML (the example sheds no light for me).

I am also interested to see which databases provide a 'Physical ROWID'. I know Oracle does but do any other Databases make such a Physical ROWID available?

I am interested in using Physical RowId from an ORM perspective.
Refer: http://www.avaje.org/rowid.html