Pooling is great - except it's not very tunable, it's hard to map end users back to connections in the pool, and if a connection ever becomes invalid inside the pool, expunging only that connection from the pool is nearly impossible; JDBC 4.0 addresses all these drawbacks

As a member of every previous JDBC Expert Group, it sometimes seems as if the specification process moves too slowly for the few features being added or it seems as if the new feature list is good, but "not good enough." The JDBC 4.0 specification fits neither of these perceptions. The specification includes a lot of new features - too many, in fact, to describe in this article. As this article was written a few months before the publication of the public draft of the JDBC 4.0 specification, it's possible that some features, features even more significant than those described here, might make it into the preview release. Most developers will be pleasantly surprised at the enhancement list, which includes everything from performance-tuning options to support for extended-level database features. Here we'll describe in detail some of the new features that are available in JDBC 4.0, along with the reasons why those features are important.

The JDBC 4.0 specification is now in public review and will ship as part of J2SE 6.0 sometime in 2006. The key goals of the JDBC Expert Group were to align with the most important features of the SQL 2003 specification, provide constructs that help improve developer productivity (sometimes called Ease of Development or EOD features), fine tune pooling constructs, and improve scalability. Unlike the JDBC 3.0 specification, there are some major new additions in the JDBC 4.0 spec, such as XML support. Overall, it's not just a collection of bug fixes to the JDBC 3.0 specification; JDBC 4.0 is clearly a significant advance of the standard.

XML Support
One of the most useful new features in JDBC 4.0 is support for the SQL 2003 XML data type. That is, the JDBC spec has been expanded to support XML data types in the database, Java XML bindings, and SQL/XML extensions to the SQL grammar. Although many databases support XML data types today, applications must use either JDBC driver extensions to transfer data to or from the database or use the Clob interface, which is limited in nature to a string representation of the XML.

A new SQL data type, SQLXML, is part of the specification. Applications can use getTypeInfo() to determine if their database supports a native XML data type. For example, getTypeInfo() against a SQL Server 2000 instance doesn't return a result row corresponding to the SQLXML data type, indicating that there's no native XML data type available for that particular database backend. By contrast, getTypeInfo() against a SQL Server 2005 instance returns a result row, indicating that an XML data type is available. It also returns information indicating that the native type name is "XML." From this information, applications can create tables that contain columns of the XML data type.

So applications can populate data in XML columns and retrieve data from those columns, JDBC has been expanded to include native Java bindings for XML. Initially, the Expert Group looked at adding all types of XML bindings, such as text, JAXP, DOM, JDOM, SAX, stream, and StAX. In the end, allowing so many different bindings had too many drawbacks. The Expert Group decided to allow bindings for Java strings, Java character streams, and StAX.

If an application needs to process data inside DOM or SAX, for example, it's a straightforward exercise to convert that data from a StAX stream to those representations.

To create a Java construct that can be used to process XML data, an application can create a SQLXML object off of the Connection object using the createSQLXML() method. The object that's created doesn't contain any data initially. Data can be added to the object by calling setString() or associating an XML stream using createXMLStreamWriter() with the object. The following code illustrates how an application can use these techniques to insert a row containing XML data into a table.

Similarly, applications can retrieve a string representation of the XML using the getString() method of the object or by associating an XML stream using createXMLStreamReader(). The following code illustrates how an application can SELECT a column of the SQLXML data type, create a SQLXML Java binding using getSQLXML() on the result set, and read the value into the new object using a StAX representation via createXMLStreamReader().