commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 8620] - Closed Connection Exception on setAutoCommit
Date Mon, 29 Apr 2002 19:03:33 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8620>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8620

Closed Connection Exception on setAutoCommit

rwaldhof@us.britannica.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID



------- Additional Comments From rwaldhof@us.britannica.com  2002-04-29 19:03 -------
> Now I'm having another problem.  When I do 
> call close() on  my connection, the PreparedStatements 
> aren't being closed, unless I close them 
> myself.  Shouldn't close() close the statements 
> as well?

I'm not exactly sure. The JDBC JavaDocs don't seem very specific on this point, 
and I don't find any mention of it in the JBDC 2.x specs.  Here's the JDBC 3.0 
specification, section 11.6.2:

"Closing a Pooled Statement
An application closes a pooled statement exactly the same way it closes a 
nonpooled statement. Whether it is pooled or not, a statement that has been 
closed is no longer available for use by the application, and an attempt to 
reuse it will cause an exception to be thrown.

The following methods can close a pooled statement:

* Statement.close  called by an application; if the statement is being pooled,
closes the logical statement used by the application but does not close the
physical statement being pooled

* Connection.close  called by an application

 * Nonpooled connection  closes the physical connection and all statements
created by that connection. This is necessary because the garbage collection
mechanism is unable to detect when externally managed resources can be
released.

 * Pooled connection  closes the logical connection and the logical statements 
it returned but leaves open the underlying PooledConnection object and any
associated pooled statements"

But that's not totally clear to me either. In your case, we're pooling 
connections but not statements.  Should we close them in that case?

I don't think we're really doing a full JDBC 3.0 connection pooling impl anyway.

The best practice would probably be to close the statements on your own 
anyway.  Certainly the current DBCP impl won't make an effort to close them for 
you (although the underlying driver implementations might on a real close).  
Someone with a better understanding of the spec than I will need to tell me if 
there's a bug there or not. 

If there's a bug, please submit submit it as a new Bugzilla entry.

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message