ResultSet vs RowSet: Which one to choose and when?

Question

So I'm aware of some relative differences i.e., the ResultSet has an 'open connection' to the database whereas a RowSet works in a 'disconnected' fashion.

But that's pretty much what I understand (may be incorrect):

My question is then this - under what circumstances is one preferable over the other? What are each of their strengths/weaknesses?

• From what I feel a RowSet, working in disconnected mode especially for "read-only" queries, would have better performance in a highly concurrent system. Is that correct? If that's the case is it safe to say RowSet is always preferable to ResultSet for readonly queries?

• If I'm correct iterating over the RowSet doesn't throw SQL Exceptions, but is that a benefit? The other being that RowSet is serializable. But my concern is primarily from a performance perspective what would be the choice?

• But does it even matter for read-write queries?? Can you sync the ResultSet back to the DB? (I'm not sure if that's possible (It may be and I just can't recollect or google it well enough :) It's been a while with raw JDBC...

Any ideas? There are some missing gaps in my knowledge as is evident :)

The reason I ask is I'd like to choose between implementing Spring-JDBC's ResultSetExtractor Interface versus return an SqlRowSet when processing some data. This question just got me curious to how to decide what to choose when, other than tossing a coin :)

Answer 1

I disagree with JR's answer. The RowSet is often a good choice, but as always, the best answer depends on your situation and your needs. Using a RowSet for everything won't yield dysfunctional code, but it can offer slower performance than a ResultSet (the common JdbcRowSet implementation is a wrapper for a ResultSet).

If you need to use your result object in modular code that requires a JavaBean, then RowSets meet the minimum requirements for Java Beans.

If you are developing code for a multithreaded/server app, then you must accept the concession that all Java Beans are mutable and therefore not thread-safe. As a result, neither Resultset nor RowSets are thread safe.

If you are writing code that consumes database queries and translates them into Java data model objects for use in the rest of your application, then it is likely that RowSets are less performant than Resultsets.

In a lot of code that I've been writing, when I receive a JDBC database query, I've been simply using the Resultset to process the retrievd rows immediately into a List of data model objects. The Resultset doesn't even survive the method call that performs the translation. In my opinion, this is good ... because Resultsets (and therefore RowSets) consume a lot of resources, and you want them to be available for gc as soon as you can.

In this mode, I don't even need any of the newer features of Resultset, let alone RowSet. I simply iterate forward once through the set and generate a List of result rows.

There are situations in which RowSets are highly desirable. Since RowSets are serializable and ostensibly "lightweight", the disconnected CachedRowSet (for example) represents a reasonably efficient mechanism for transmitting database query results between locations, particularly if you want the data to be updateable in situ. Of course, you could also serialize and transmit a List of objects.