Kathey Marsden wrote:
Philip Wilder wrote:
Can anyone give me an explanation on the importance of the forMetaData
boolean found in the org.apache.derby.jdbc.EmbedStatement class and
subsequently passed on to any org.apache.derby.jdbc.EmbedResultSet
class? I'm having difficulty comprehending why DatabaseMetaData
ResultSets are given more weight then any other ResultSets.
Hi Philip,
No firm answers on this but just a couple of research pointers.
In the jdbcapi/metadata.java test there is a case.
rs = s.executeQuery("SELECT * FROM SYS.SYSTABLES");
System.out.println("getColumns('SYSTABLES'):");
ResultSet rs2 = met.getColumns("", "SYS", "SYSTABLES", null);
if (!rs.next()) {
System.out.println("FAIL -- user result set closed by"+
" intervening getColumns request");
}
Which seems to imply that the results from the metadata call are all
cached up and perhaps the special handling keeps that process from
interfering with the user statement. Actually for this case to be
useful, the test should set holdability on the connection to
CLOSE_CURSORS_AT_COMMIT. With the current Derby
default,HOLD_CURSORS_OVER_COMMIT, this test would pass regardless of
whether the results were cached or not.
You might also check the JDBC spec for information on special handling
of metadata with regard to leaving queries open on the database. I am
guessing the fact that the Statement object is never returned to the
user complicates things somewhat for metadata..
Hope that helps
Kathey
#####################
For the curious I think I may have come up with an answer to my own question.
Not surprisingly the forMetaData tag is used for Statements associated with the
DatabaseMetaData object. The purpose of this tag is to insure that
DatabaseMetaData will never interfere with Statement objects created by the
user. Without this tag any time any of the getXXX() methods that return a
ResultSet are called from DatabaseMetaData or any time those ResultSets would
finish they would cause a commit which is potentially problematic to the user.
This is particularly the case if the option CLOSE_CURSORS_AT_COMMIT was used in
generating Statement objects. I think my problem in looking at this issue
originally was the erroneous perception that commits were dealt with on a per
Statement basis.
I have yet to find any JDBC documentation supporting this behavior but the
search is on going.
Philip
