[
https://issues.apache.org/jira/browse/DERBY-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583724#action_12583724
]
Knut Anders Hatlen commented on DERBY-3319:
-------------------------------------------
Let's see if I understand this issue correctly. Based on experiments with the
attached test case, I think this is how the drivers behave:
1. close() on logical connections with active transactions does not fail and
resources are not freed (both embedded and client)
2. EmbedPooledConnection.getConnection() issues a rollback on the physical
connection
3. ClientPooledConnection.getConnection() does not issue a rollback on the
physical connection if the previous logical connection has been closed
4. ClientPooledConnection.getConnection() issues a rollback on the physical
connection if the previous logical connection has not been closed
Does that sound about right?
> 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.
