JDBC 2 Core

Specification released for public review June, 1998.

Download from http://java.sun.com/jdbc

The jdbc 2 core api was released for public review on june 1, 1998. As well as providing new database functionality, one of the goals of jdbc 2 is to leverage the new java technology which was released subsequently to jdbc 1. jdbc 1 was released with the jdk 1.0, and did not integrate with the new technology released in jdk 1.1 and 1.2. When jdbc 1 was released, there was no java beans component model. Under the java beans component model, a jdbc 2 rowset (part of jdbc 2 extension api) will be a serializable java bean. Jdbc 2 core will make use of the new internationalization features of the jdk 1.1.

Think of the new jdbc 2 java.sql package as a superset of the old jdbc 1 java.sql package. So jdbc 1 applications will continue to work under jdk 1.2, but they'll require new jdbc 2 drivers which support the new java.sql interfaces in jdk 1.2. InterClient will provide a driver for jdk 1.2, jdbc 2 methods which are not yet implemented will throw a SQLException.

Because of widely disparate capabilities of various dbms, almost everything new in jdbc 2 is optional.

Due to public review and beta use of the jdbc 2 core api as part of the jdk 1.2 beta, some new interface methods will be added in the final release which do not currently appear in the downloadable jdbc 2 specification as of today, August 30, 1998.

• Advanced datatypes
  Required for compliance.
  Blob and Clobs and Array support from SQL3. We're currently working on the Array support.
• User defined types
  This is optional for compliance as it relies on object engine capabilities.
  The jdbc 2 designers invision 3 kinds of jdbc drivers/databases in the future. Those that support SQL 3 user defined structured types and refs, or those that support persistent storage of Java objects (aka extended relational system), or those that support the traditional SQL 2 relational model. I won't venture into this political arena, but it may be that if you want to store objects, you should either use an object relational mapping, or you should use a pure java object oriented database.
• Performance hints
  User directed performance hints to the driver.
  setFetchSize(int numRows) tells the driver how many rows to prefetch and cache on the client.
  When a result set is created, a suggestion can be made to the driver as to the intended direction of traversal, eg. forward only. Drivers are allowed to ignore these suggestions, but interclient won't. We've already implemented the setFetchSize() method.
• Batched updates
  This will yield huge performance improvements, especially when working over the network. This is a way to roll up, or batch up, a set of pending update statements into a single server request to be sent over the network. So a batched update may consist of several update, delete or insert statements heterogeneously which can all be sent as a single request to the server. Batched updates also allows for multiple inputs to a single prepared statement to be sent all at once to the server. In jdbc 1, each new set of inputs results in a separate request for a prepared statement execution which would have to be relayed over the network to the server. This is purely driver functionality requiring no new support from the engine. InterClient will incorporate this in a future release.
• Result set enhancements
  This includes scrollable cursors and updatable result sets. Scrollable cursors is optional for compliance but according to the jdbc designers at javasoft, this is the most requested feature. Scrollable cursors support relative and absolute positioning, forwards and backwards movement thru a result set. Scrollable cursors will require significant driver and engine support. Much work has already been done in InterBase towards engine-capable scrollable cursors, as well as work in the remote interface and the InterBase C client library. Once supported, InterClient will plug into InterBase's engine-capable scrollable cursors, and provide its own remote interface in the pure java client library.

  There are two basic kinds of results sets - scrollable or forward only.
  And there are two basic kinds of scrollable result sets - sensitive and insensitive [cursors].
  Sensitive result sets are sensitive to changes made by other transactions, insensitive result sets are not even sensitive to changes made within their own transaction.
  Sensitive result sets may not sense all changes if setFetchSize() is greater than 1 because of client-side row caching by the driver. refreshRows() has been added recently to jdbc 2 to allow for sensitivity to row changes that might not otherwise be seen in a client cached row.
  Updatable result sets will be supported using either database write locks or an optimistic concurrency scheme in which, when rows are updated, the old row values are compared to current values in the database to determine if an update conflict has occurred. The optimistic concurrency algorithm is provided within the driver, not requiring database locks, and can in fact allow for disconnected rowset capability for mobile computing.
  Read only result sets will also be supported
  New ways of doing positioned updates and deletes, which was not well supported in jdbc 1 and not universally supported by drivers.

• Character streaming
  The facilities for streaming characters didn't exist in the jdk 1.0 when jdbc 1 was released.