Hi,
According to the .trace.db file, this isn't a bug in H2, but actually
a problem in the application. It works for HSQLDB because HSQLDB
doesn't follow the JDBC specification in this case. What happens in H2
is: the application tries to read from a result set that is already
closed, because the the statement that produced the result set was
re-run. This doesn't fail with HSQLDB because it doesn't close the old
result set, which is a violation of the JDBC specification. Test case:
stat.execute("create table test(id int)");
stat.execute("insert into test values(1)");
PreparedStatement prep = conn.prepareStatement("select * from test");
ResultSet rs1 = prep.executeQuery();
prep.executeQuery();
rs1.next();
According to my test, the last line (rs1.next()) fails for H2,
PostgreSQL, MySQL, and Apache Derby (and fail with all databases that
follow the JDBC specification in this regard). It works for HSQLDB.
I found out this is the problem using the .trace.db file:
line 3859: ResultSet rs147 = prep34.executeQuery();
line 3940: ResultSet rs149 = prep34.executeQuery();
line 3952: rs147.next();
The relevant text in the JDBC specification is in the ResultSet class
level Javadoc, "A ResultSet object is automatically closed when the
Statement object that generated it is closed, re-executed, or used to
retrieve the next result from a sequence of multiple results."
By the way, h2.serverCachedObjects only applies to the TCP server (as
documented), but you are using an embedded database, so
h2.serverCachedObjects can't possibly help.
Regards,
Thomas
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
