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: JDBC auto-commit semantics challenge
Date Thu, 14 Jul 2005 19:40:09 GMT
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