[
https://issues.apache.org/jira/browse/DERBY-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609618#action_12609618
]
Knut Anders Hatlen commented on DERBY-3319:
-------------------------------------------
Regarding the "connection stealing", it seems like that's what
ClientPooledConnection, ClientXAConnection and EmbedPooledConnection do.
However, EmbedXAConnection only steals the connection if it is not part of a
global connection. If it is part of a global XA connection, an exception is
thrown. Here's the relevant code and comment in
EmbedXAConnection.getConnection():
if (currentConnectionHandle != null) {
// this can only happen if someone called
start(Xid),
// getConnection, getConnection (and we are now
the 2nd
// getConnection call).
// Cannot yank a global connection away like, I
don't think...
throw Util.generateCsSQLException(
SQLState.CANNOT_CLOSE_ACTIVE_XA_CONNECTION);
}
I'm not sure what the correct approach is in this case. For pooled connections,
I see that it makes sense to allow stealing the connection and aborting the
active transaction because of the reasons Kristian mentioned above, but it's
not clear to me if the same would apply to global XA connections.
One difference between pooled connections and XA connections in this respect is
that PooledConnection.getConnection() is expected to return a fresh logical
connection that executes in a different transaction than the previous logical
connection, whereas the connection returned by XAConnection.getConnection() is
expected to execute in the same global transaction as the previous logical
connection did. At least, J2EEDataSourceTest is testing that they behave this
way, so I assume that it is expected.
> 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.
