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 Thu, 09 Feb 2006 14:44:01 GMT
Yep false is a winner here  in this case.

David W. Van Couvering wrote:

> Thanks, Lance.  I understand the motivation for the method.  My 
> question, is how do we respond to it.  It appears like result sets are 
> closed if the severity of the exception is high enough, but that's not 
> what this API seems to be asking about it.  It seems to ask if *any* 
> SQLException is a guarantee that result sets are closed.
>
> Since we don't *always* close result sets, even though we do it in 
> *some* cases, baesd on my interpretation of the semantics of this 
> method, I will need to answer false.  I just want to make sure there 
> are no objections.
>
> David
>
> Lance J. Andersen wrote:
>
>> 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
>>
>>
>>

Mime
View raw message