3

After hours of search I finally realized that java.sql.ResultSet is not Serializable neither there's a way to do that. I tried adding to a List, as an instance variable in a Serializable object and other stuff but things turned out to be naive and desperate attempts. I tried to uses the implementations of RowSet like CachedRowSetImpl that are Serializable but they increase the response time, most probably because they iterate the ResultSet. Bottom line, until or unless you choose to iterate ResultSet, you can't send the data it contains over a network.

I know the alternatives that I must iterate and add contents to a data model object and a list but I desperatly want to know what is the rational behind this? What do the developers of java thought at that time?

ares
  • 4,283
  • 6
  • 32
  • 63
  • As you said, "Bottom line, until or unless you choose to iterate ResultSet, you can't send the data it contains over a network." What makes you think it would be any different if `ResultSet` was Serializable, or that you wouldn't have to iterate the `ResultSet` in order to serialize the object? – Tim Jul 21 '14 at 16:36

2 Answers2

9

As far as I know the ResultSet does not "contain" the data. If you call http://docs.oracle.com/javase/7/docs/api/java/sql/ResultSet.html#next() the ResultSet will get the data from the underlying (JDBC) connection to the database.

This would be impossible, if the ResultSet was i.e. serialized and transferred to a different computer. There the connection would be unavailable.

Markus Patt
  • 467
  • 3
  • 11
  • Thank you, that's precise and accurate. Perfectly answered the why part? – ares Jul 22 '14 at 06:10
  • 3
    The ResultSet can contain batches of data. That's what the 'fetchSize()' property is for. The real issue is that it contains a live connection, which inherently isn't serializable. – user207421 Jul 22 '14 at 23:57
  • @EJP, As per your comment, it looks like ResultSetImpl (driver impl.) contains members which are not serializable. Let me know whether my understanding is correct or not. Also above answer seems to be so incorrect, but still got accepted. – bharatj Oct 06 '15 at 17:33
  • What is the practical difference between a resultset and an array in a java context though? Can´t you just create an array from the resultset and serialize that instead?! – Lealo Aug 13 '17 at 01:23
  • An `array` is a data structure which holds the data whereas a `ResultSet` contains a live connection which will fetch the data when called for. ResultSet also may contain batches of data with an eager loading strategy but that depends on driver implementation. – ares Aug 13 '17 at 05:27
0

I can not answer what original developers thought of, but some elements are clearly exposed by the design of the interface.

First, let's note that ResultSet is an interface, the designers did not intend it to be serializable or not.

But still, ResultSet is such a powerfull interface, that it hardly makes sense for it to be generally serializable. A few examples.

  1. ResultSet participates in transactionnal behavior. If the result set was to be serialized, and sent elsewhere (to a file, to another JVM via RMI...) what happens to the original transaction ?
  2. ResultSet allows for direct update of columns in rows, or even row deletion. If the result set was to be serialized and sent elsewhere, how would that work ?
  3. ResultSet allows for the Streaming of some types of columns (*LOB). How would streaming work in a seriliazable context ?
  4. How would methods such has refresh work when (de)serialized ?

These are a few of the non-trivial questions that arise when you think about ResultSet serialization.

It seems to me that ResultSet was designed, and somehow optimized, to reflect a direct and live connection to a relational database, not a Set of "portable" datas.

The examples above are a clear sign that a serializable ResultSet implementation could have restriction on its implementation once deserialized (update methods would essentially be no-ops).

Plus, it seems inevitable that trying to serialize the content of the result set implies the need to iterate it "somehow" : the content is inevitably linked to the fetching of all datas in the resultSet (maybe implementors could optimize the process so as not to parse it fully, only getting raw bytes for the database, but you would still need to fetch the datas in order to serialize them).

So, it is my opinion that designers and most implementors of the ResultSet interface cared more about the live aspect of a ResultSet (ability to participate in transactionnal behavior and writeBack to the DB using update methods) than its serialization (or serializability). That said, given sufficient contraints on the implementation (like no-oping the update methods, and disabling streaming capabilities), it certainly is possible to make a serializable implementations.

GPI
  • 9,088
  • 2
  • 31
  • 38