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 "Knut Anders Hatlen (JIRA)" <ji...@apache.org> on 2008/07/01 17:18:45 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=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.