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: JDBC auto-commit semantics challenge
Date Mon, 18 Jul 2005 18:08:22 GMT
Philip,

Thanks for this.   I will discuss with the JDBC 4 EG and report back.

-lance

Philip Wilder wrote:

> Lance,
>
>
> In order to further distill this issue for your EG team I've created 
> this brief question list (largely based off some earlier questions 
> from Kathey) that you can pass on to them. As always let me know if 
> there is any way I can further clarify this issue.
>
> Philip
>
> #########
>
> 1) Section 9.1 of the JDBC specification document says
>
> "The result set is closed no later than when one of the following 
> occurs: ...
> When ResultSet is Holdable:
> a.
> if the cursor is forward only, then when invocation of its next method 
> returns false "
> Should a ResultSet really be closed in this manner regardless of 
> holdability? If so, after a cursor is closed in this manner (or via 
> any other method) what functions (if any) can be called without 
> throwing an Exception? For example will a call to ResultSet#next() 
> return false or throw an Exception?
>
> 2) How should DatabaseMetaData calls affect auto-commit? Since the 
> statement itself is not exposed, should execution completion of a 
> metadata call send an auto-commit or should there be special handling 
> to avoid this? There is no known reference to this issue in the JDBC 
> 4.0 specification.
> 3) Section 9.1 of the JDBC 4.0 specification states:
>
> "For CallableStatement objects or for statements that return multiple 
> results,
> the statement is complete when all of the associated result sets have 
> been closed."
>
> Yet the associated Connection#setAutoCommit() Java Documentation states:
> "In advanced cases, a single statement may return multiple results as 
> well as output parameter values. In these cases, the commit occurs 
> when all results and output parameter values have been retrieved."
>
> Are these documents in conflicting, why or why not?
>

Mime
View raw message