You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by de...@db.apache.org on 2004/10/04 18:19:33 UTC
[jira] Closed: (DERBY-24) Client should not be able to raise an event on a PooledConnection it no longer owns.
Message:
The following issue has been closed.
Resolver: Daniel John Debrunner
Date: Mon, 4 Oct 2004 9:18 AM
Fixed in commited revision 53730
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/DERBY-24
Here is an overview of the issue:
---------------------------------------------------------------------
Key: DERBY-24
Summary: Client should not be able to raise an event on a PooledConnection it no longer owns.
Type: Bug
Status: Closed
Priority: Minor
Resolution: FIXED
Project: Derby
Components:
JDBC
Fix Fors:
10.0.2.0
Versions:
10.0.2.0
Assignee: Daniel John Debrunner
Reporter: Ramandeep Kaur
Created: Wed, 29 Sep 2004 12:40 PM
Updated: Mon, 4 Oct 2004 9:18 AM
Description:
Opening this bug on behalf of Daniel Debrunner.
---------------------------------------------------------------
After closing a connection Derby generates a connectionErrorOccurred() event on the PooledConnection when a createStatement() call is made against the closed Connection.
The code gets a Connection from the PooledConnection, creates a
Statement, and then closes the Connection. This causes a
connectionClose() event, like it's supposed to. Then it closes
it again, which does not raise an exception (the spec doesn't
really say what should happen if you close it twice, so it's
hard to claim this is an error...). A second connectionClose()
event is not generated, which is fine.
The testcase then calls createStatement() again on the closed
Connection. This generates a connectionErrorOccurred() event
on the PooledConnection, which seems wrong. The connection
pool code at this point is going to figure that the
PooledConnection is bad and needs to be discarded, even though
it's fine. (The second createStatement() call receives a
SQLException, which is fine.)
The code which receives the error event has to assume that the
event is associated with the current user of the
PooledConnection. When the first Connection.close() occurs, we
will move the PooledConnection into the free pool, and then
assign it to the next Connection requester. If the first
Connection client erroneously calls createStatement() on their
closed Connection facade, the Derby Connection facade
generates that error event which refers to the PooledConnection
now being used by the second client. But the code will have to
assume that the second Connection client received an
unrecoverable error, and that the PooledConnection needs to be
closed, when in fact the first connection client has made a
programming error. There's no way for to tell which client
caused the error.
The upshot is that any events should be generated after the close event caused by close(), no matter what is done to that closed Connection facade, since the client's not supposed to be using it anymore.
The reference for connection pooling semantics is:
http://java.sun.com/products/jdbc/jdbc20.stdext.pdf
It doesn't explicitly say what should happen if an error occurs
on a closed Connection, but it seems like the current behavior
will confuse the connection pool built on top of
PooledConnection.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira