Philip Wilder wrote: > 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.
Yep, that's the reason. > I think my problem in looking at this > issue originally was the erroneous perception that commits were dealt > with on a per Statement basis. Technically I think auto-commit mode is at the statement level. Section 10.1 of JDBC 3.0 documents auto-commit mode in terms of statements, not ResultSet objects. But a query statement produces a ResultSet and actions on such ResultSets (not all ResultSets) affect the auto-commit logic. However Derby uses the same implementation for all ResultSet's, thus some flag to change behaviour is required. > I have yet to find any JDBC documentation supporting this behavior but > the search is on going. I think it's implied from 10.1, auto-commit only applies to the *statements* listed there, thus ResultSet's from DatabaseMetaData have nothing to do with auto-commit. Dan.
