db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philip Wilder <0505...@acadiau.ca>
Subject Re: forMetaData
Date Mon, 20 Jun 2005 21:22:54 GMT
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


Mime
View raw message