db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: Paging Lance: Closing result sets on exception
Date Wed, 08 Feb 2006 22:22:44 GMT
This method was added as various drivers and database vendors all do 
this differently.  In some cases autocommit  is handled explictly by the 
drivers themselves, not the backend.

autocommit has been very problematic over the years and somedays it 
would be great it it never existed....

David W. Van Couvering wrote:

> Hi, all (and especially Lance).  I just ran this test:
> - Create a statement that is scrollabe and read-only
> - Execute a select on the statement
> - Attempt to update the row, catch the exception
> - Call rs.beforeFirst().  Looking at the embedded code, if the result 
> set is closed, this should cause an exception saying the result set is 
> closed.
> My test indicates that the result set is not closed, independent of 
> whether it is holdable or not.  But this makes sense.  What database 
> would want to close a result set just because someone tries to update it?
> That said, I am trying to answer the question to the new metadata call
> autoCommitFailureClosesAllResultSets()
> where the javadoc states
> "Retrieves whether a SQLException while autoCommit is true inidcates 
> that all open ResultSets are closed, even ones that are holdable. When 
> a SQLException occurs while autocommit is true, it is vendor specific 
> whether the JDBC driver responds with a commit operation, a rollback 
> operation, or by doing neither a commit nor a rollback. A potential 
> result of this difference is in whether or not holdable ResultSets are 
> closed."
> Based on this javadoc, it looks like our answer should be "false."  
> But is this the correct interpretation?  Is there a better way to test 
> this?  I feel like I'm not quite understanding the intention of this 
> metadata call.
> Thanks,
> David

View raw message