db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3319) Logical connections do not check if a transaction is active on close
Date Tue, 01 Jul 2008 15:18:45 GMT

    [ 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.


Mime
View raw message