[
https://issues.apache.org/jira/browse/DERBY-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610917#action_12610917
]
Knut Anders Hatlen commented on DERBY-3319:
-------------------------------------------
Currently, plain connections (from DriverManager) throw an exception on close
if they have uncommitted operations and they have auto-commit off. I think
connections that come from data sources should behave the same way, but if the
connection is associated with an XA transaction, I think it should not throw an
exception because
a) the connection object doesn't control commit/rollback. Even if the
connection is closed, the global transaction can still be committed or rolled
back with the XAResource. I think the rationale for disallowing close on plain
connections when the transaction is active, is that there's no way to end the
transaction after the connection is closed. Since this is not the case for XA
transactions, there's no need to throw the exception.
b) there are regression tests that depend on the ability to close a
connection before ending the associated XA transaction (sequences like
XAResource.start() ... XAConnection.getConnection() ... Connection.close() ...
XAConnection.getConnection() ... Connection.close() ... XAResource.end()) so
keeping the current behaviour for these connections sounds safer
Unless there are objections to this approach, I'll post a patch which
implements this new behaviour.
> 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.1.3, 10.5.0.0
> Environment: Embedded driver and client driver.
> Reporter: Kristian Waagan
> Assignee: Knut Anders Hatlen
> 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.
