We have just posted our public review of the JDBC RowSet Implementations specification (JSR-114). This is penultimate draft before we finalize the standard in our Final Draft.

The JDBC RowSet Implementations specification seeks to define the standard API's for implementations of the RowSet interface. These implementations are focused on providing the facilities needed by developers wanting to pass tabular data between distributed tiers and components and defines the XML Schema that is be used to represent the RowSet objects that are passed between components.

Download the JSR 114: JDBC RowSet Implementations Proposed Final Draft

The JSR 114 API is targeted at two distinct audiences:

- Driver vendors that implement the JDBC API and intend to provide standard JDBC RowSet implementations.
- ASP's that provide middle-tier services above the JDBC driver layer

The specification is also intended to serve the following purposes:

- An introduction for end-users whose applications use the JDBC RowSet implementations
- A starting point for developers of other APIs layered on top of the JDBC API

View the JSR 114 Home Page: http://jcp.org/en/jsr/detail?id=114

we still need credible solution for large result set iterator, last discussed here -- http://www.theserverside.com/home/thread.jsp?thread_id=13939

Yes, pagination is needed.

Also, RowSet uses DataSource, not connection therefore...:
JDBC 4.0 should deprecate Connection and ResultSet, people just have problems with it. Data connectivity stability is listed as #1 J2EE problem, and by forcing JDBC drivers to support RowSet and DataSorucePool, it solves a lot.

We also need at toCollection for entire rowset and toXML for entire rowset, as well as a constructors:
new RowSet(Collection c)
new RowSet(Document XML)


This way I can pass in XML to update my DB.

.V

> JDBC 4.0 should deprecate Connection and ResultSet, people just have problems with it. Data connectivity stability is listed as #1 J2EE problem, and by forcing JDBC drivers to support RowSet and DataSorucePool, it solves a lot.


Why ? Why deprecate Connection and ResultSet ? There will always exist programs outside applications servers (J2EE), which are happy enough with Connection and ResultSet, which do not need anything else. There could be some utility programs, integration programs and whatever the purpose is. J2EE is not the whole world, it always cost money, for the application server itself or at least for hardware and maintaining, and there will always be smaller/simple solutions without J2EE.

On the other hand, for the purpose of avoiding mess in J2EE, Connection and (maybe) ResultSet could be deprecated as it is with some other thing, such as manual work with sockets, etc. But outside the scope of J2EE server - full functionality

Im quite confused why do you guys think that either Connection Or ResultSets should be deprecated?

Cheers

Smythe

You can use DataSource anyplace where you can use Connection.
You can use RowSet anyplace where you can use ResulstSet.

THye are better, more modern, etc. Plus people do not write a double nested finnaly to release the connection.
DataSource+RowSet eliminates the need for that, and does everything else the other 2 did, you lose nothing. You can use it outside of J2EE in Applets or what ever.

But some vendor JDBC drivers do not support DataSource and RowSet well. By deprecating the old, it forces them to re-write the old drivers.

It's just like util.Date, we should now use Calendar.

A lot of JDBC books talk about JDBC 1.0, so they need to get outdated. Also, people should be using DAO, and not JDBC.

One of the main problems with stability of J2EE apps is database connectivity.... and it should be addressed somehow!

.V