db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: ResultSet.getConcurrency() behaves differently on client and embedded
Date Mon, 27 Feb 2006 13:51:36 GMT
Knut Anders Hatlen wrote:
> "Lance J. Andersen" <Lance.Andersen@Sun.COM> writes:
> 
>> We clarified this in JDBC 4 spec
>>
>>
>> Once a ResultSet has been closed, any attempt to access any of its
>> methods with
>> the exception of the isClosed method will result in a SQLException being
>> thrown. ResultSetMetaData instances that were created by a ResultSet that
>> has been closed are still accessible.
> 
> Thanks, Lance! I'll go through all the ResultSet methods and file a
> JIRA.
> 
> Does the same apply for Statement? I didn't see a similar comment
> about Statement objects in the spec.
> 

Hi Knut Anders,

I don't exactly have an answer for you, but observed the following in 
the 'EmbedStatement.java' file:
"/* The close() method is the only method
   * that is allowed to be called on a closed
   * Statement, as per Jon Ellis.
   */"

I found in the JDBC4 spec that Jon Ellis is a former JDBC spec lead. It 
is also stated in a comment that every public method in the class must 
call 'checkStatus', which throws an SQLException if the statment is closed.

For the close method itself, the JDBC4 JavaDoc says this:
"Calling the method close on a Statement object that is already closed 
has no effect."

Derby seem to behave according to the spec on this point, but maybe 
someone else has something more to add?



--
Kristian


Mime
View raw message