db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: forMetaData
Date Mon, 20 Jun 2005 21:37:02 GMT
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.



Mime
View raw message