The JDBC RowSet Implementations specification has just passed Final Ballot in the Java Community Process. The represents the final approval milestone in the JCP process:

http://jcp.org/en/jsr/results?id=2500

We will be shortly posting our Final Release on the JDBC Technology homepage, which include the FCS binary, and specification.

http://java.sun.com/products/jdbc

-Jonathan Bruce
JDBC Spec. Lead & Architect
Sun Microsystems Inc.

JSR-114 was initiated in April 2001:

  http://jcp.org/en/jsr/detail?id=114

Why did it take so long to reach the final ballot?

For web applications, particularly portal applications, Cached Row Sets imply persistent database connections. For Portal applications, this potentially implies one persistent connection per portlet. A busy user clicks around on 3 or 4 portal pages and they've just instantiated 30 database connections at a cost of 4-5MB each. That's 200MB of RAM per user. On a system with 2000 concurrent users (a typical major enterpise application) That's 20 terabytes of RAM. Cached Rowsets are totally impractical.

Forgive my math. 240GB of RAM for 2000 users with 30 database connections each at 4MB per connection, but still you get my point. Cached RowSets are not scalable.

Forgive my math. 240GB of RAM for 2000 users with 30 database connections each at 4MB per connection, but still you get my point. Cached RowSets are not scalable.

Reading a specification can indeed be very helpful. CachedRowsets are disconnected Rowsets that cache their content in memory. It can even be serialised, if need be. This is a technology that has been around in Microsoft's ADO.NET for a long time and that was long overdue in Java. It may have a scalability problem - if you don't use it properly, but that has nothing to do with database connections.

Yes, it can use a lot of memory and it is not scalable if cache size depends on user count, you must not have cache specific for user (like resultsets in http session), but global MRU cache for all users with common data for all users can increase performance and scalability (It does not means you need to cache evrything)

They may be memory hogs but I think you've got it backwards regarding connections. CachedRowSets may become disconnected, releasing the connection back to the pool.

Taylor

I have tried current RowSet implementation and I was completely disappointed. So many bugs and design flaws, I even can't list all here.

For example, _all_ exception processing code looks like this (I have no sources, of course, but I can see exception data in debugger):

... somewhere in WebRowSetXmlReader
catch(SAXParseException e) {
   System.out.println(...); // Some error reporting here in stdout
   throw new SQLException(e.getMessage());
}

So, after this SAX exception was "processed" and rethrown as SQLException, all info about real XML parsing error was completely lost - I have access to message only, no exception itself.

Another example - RowSet acceptChanges() method. At this time one SQLException data was lost during "processing", and we get only "acceptChanges failed" exception message - no more info about failure reason.

Very, very bad code...

Well, nobody told that implementation was production-ready...

Well, do not need make this release

For example, _all_ exception processing code looks like this (I have no sources, of course, but I can see exception data in debugger):... somewhere in WebRowSetXmlReadercatch(SAXParseException e) {   System.out.println(...); // Some error reporting here in stdout   throw new SQLException(e.getMessage());}So, after this SAX exception was "processed" and rethrown as SQLException, all info about real XML parsing error was completely lost - I have access to message only, no exception itself.Another example - RowSet acceptChanges() method. At this time one SQLException data was lost during "processing", and we get only "acceptChanges failed" exception message - no more info about failure reason.

I wish that java.sql.SQLException offered full support for exception chaining.

I would like to see new constructors:
 
    public java.sql.SQLException(String reason, Throwable cause)

    public java.sql.SQLException(Throwable cause)

    public java.sql.SQLException(String reason, String sqlstate, Throwable cause)


etc.

i'd like there to be constants defined somewhere in java.sql for basic database exception errors like duplicate row, foreign key constraint error, etc. Right now, one has to do handle this differently for each database.

i'd like there to be constants defined somewhere in java.sql for basic database exception errors like duplicate row, foreign key constraint error, etc. Right now, one has to do handle this differently for each database.

http://www.springframework.org/docs/reference/dao.html#dao-exceptions

I wish that java.sql.SQLException offered full support for exception chaining.I would like to see new constructors:

You can still work around this by using the initCause(Throwable) method on SQLException, if you target JDK 1.4 or later. Seems that this is what the implementation should do.

We have just pushed our reference implementation. See our Technology hompage for details:

http://java.sun.com/products/jdbc/index.jsp

The requested object does not exist on this server. The link you followed is either outdated, inaccurate, or the server has been instructed not to let you have it.