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 "Kristian Waagan (JIRA)" <ji...@apache.org> on 2008/04/03 00:50:24 UTC
[jira] Commented: (DERBY-3319) Logical connections do not check if
a transaction is active on close
[ https://issues.apache.org/jira/browse/DERBY-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584874#action_12584874 ]
Kristian Waagan commented on DERBY-3319:
----------------------------------------
I would think points 1 is incorrect behavior. If that one is fixed, I think point 3 might be okay.
Points 2 and 4 are good. I believe it is required to be able to support "connection stealing", i.e. when a connection pool implementation executes a sequence like this:
PooledConnection pc = ...
Connection lc1 = pc.getConnection()
// Give lc1 to a user/client.
// Then wait, and determine that the user having lc1 has crashed / timed out / misbehaved.
// Take back control of the physical connection and give a new logical connection to another user.
Connection lc2 = pc.getConnection()
// lc1 will now be closed / invalidated and should not contain any reference to the pooled / physical connection.
We should not throw an exception in this case. Also note that the reference to the PooledConnection will normally not be available to end-users.
I logged this issue to get point 1 fixed.
> Logical connections do not check if a transaction is active on close
> --------------------------------------------------------------------
>
> Key: DERBY-3319
> URL: https://issues.apache.org/jira/browse/DERBY-3319
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.3.2.1, 10.4.0.0, 10.5.0.0
> Environment: Embedded driver and client driver.
> Reporter: Kristian Waagan
> Attachments: LogicalConnectionCloseActiveTransactionBug.java
>
>
> If you call close on a logical connection, for instance as obtained through a PooledConnection, it does not check if there is an active transaction.
> The close of the logical connection is allowed, and even the close of the parent PooledConnection is allowed in the client driver. This can/will cause resources to be left on the server, and later operations might fail (typically with lock timeouts because the "closed" transaction is still holding locks).
> I do not know if gc will solve this eventually, but I would say the current behavior of the client driver is wrong in any case.
> There is difference in the behavior between the embedded and the client driver, and there also seems to be a bug in the embedded driver.
> The analysis above is a bit sketchy, so it might be required to look into the issue a bit more...
> I will attach a repro (JDBC usage should be verified as well, is it legal / as intended?)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.