From derby-dev-return-92142-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Wed Dec 7 02:56:05 2011
Return-Path:
X-Original-To: apmail-db-derby-dev-archive@www.apache.org
Delivered-To: apmail-db-derby-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id 7D6347907
for ; Wed, 7 Dec 2011 02:56:05 +0000 (UTC)
Received: (qmail 76715 invoked by uid 500); 7 Dec 2011 02:56:05 -0000
Delivered-To: apmail-db-derby-dev-archive@db.apache.org
Received: (qmail 76686 invoked by uid 500); 7 Dec 2011 02:56:04 -0000
Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To:
Delivered-To: mailing list derby-dev@db.apache.org
Received: (qmail 76595 invoked by uid 99); 7 Dec 2011 02:56:04 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Dec 2011 02:56:04 +0000
X-ASF-Spam-Status: No, hits=-2001.2 required=5.0
tests=ALL_TRUSTED,RP_MATCHES_RCVD
X-Spam-Check-By: apache.org
Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Dec 2011 02:56:01 +0000
Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116])
by hel.zones.apache.org (Postfix) with ESMTP id 7CB1810420B
for ; Wed, 7 Dec 2011 02:55:40 +0000 (UTC)
Date: Wed, 7 Dec 2011 02:55:40 +0000 (UTC)
From: "Brett Bergquist (Updated) (JIRA)"
To: derby-dev@db.apache.org
Message-ID: <1124434365.48142.1323226540512.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: <1372350735.48141.1323226540480.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (DERBY-5523) XA Transactions can becomes stuck if
a connection from a XAResource without a timeout terminates after
performing work but before ending
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
X-Virus-Checked: Checked by ClamAV on apache.org
[ https://issues.apache.org/jira/browse/DERBY-5523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brett Bergquist updated DERBY-5523:
-----------------------------------
Description:
If using a connection with no timeout starts an XA transaction with
xaRes.start(xid, XAResource.TMNOFLAGS);
and some work is done but the application fails without calling
xaRes.end(xid, XAResource.TMSUCCESS)
then another application cannot join that transaction using
xaRes.start(xid, XAResource.TMJOIN)
and then commit or rollback the transaction. Basically the transaction is ACTIVE but cannot be rolled back or committed and will exist until the database server is restarted.
This is similar to DERBY-2220. With DERBY-2220, it too will not work if the XAResource does not have a timeout specified either. This is simple to test by using the test code attached to DERBY-2220 and comment out the setting of the timeout. Once doing so, the transaction will be maintained and the locks will not be released.
This might be a deviation from the XA standard but I cannot tell. It seems as if a XA connection does not have a timeout set is active (that is XAResource.start has been called but XAResource.end has not) and the connection gets closed, the XA transaction should be rolled back implicitly. This is being done if the XAResource has a timeout set so it seems that it would not be too hard to do in this case either.
was:
If using a connection with no timeout starts an XA transaction with
xaRes.start(xid, XAResource.TMNOFLAGS);
and some work is done but the application fails without calling
xaRes.end(xid, XAResource.TMSUCCESS)
then another application cannot join that transaction using
xaRes.start(xid, XAResource.TMJOIN)
and then commit or rollback the transaction. Basically the transaction is ACTIVE but cannot be rolled back or committed and will exist until the database server is restarted.
This is similar to DERBY-2220. With DERBY-2220, it to will not work if the XAResource does not have a timeout specified either. This is simple to test by using the test code attached to DERBY-2220 and comment out the setting of the timeout. Once doing so, the transaction will be maintained and the locks will not be released.
This might be a deviation from the XA standard but I cannot tell. It seems as if a XA connection does not have a timeout set is active (that is XAResource.start has been called but XAResource.end has not) and the connection gets closed, the XA transaction should be rolled back implicitly. This is being done if the XAResource has a timeout set so it seems that it would not be too hard to do in this case either.
> XA Transactions can becomes stuck if a connection from a XAResource without a timeout terminates after performing work but before ending
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5523
> URL: https://issues.apache.org/jira/browse/DERBY-5523
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.8.1.2
> Environment: Solaris 10
> Reporter: Brett Bergquist
>
> If using a connection with no timeout starts an XA transaction with
> xaRes.start(xid, XAResource.TMNOFLAGS);
> and some work is done but the application fails without calling
> xaRes.end(xid, XAResource.TMSUCCESS)
> then another application cannot join that transaction using
> xaRes.start(xid, XAResource.TMJOIN)
> and then commit or rollback the transaction. Basically the transaction is ACTIVE but cannot be rolled back or committed and will exist until the database server is restarted.
> This is similar to DERBY-2220. With DERBY-2220, it too will not work if the XAResource does not have a timeout specified either. This is simple to test by using the test code attached to DERBY-2220 and comment out the setting of the timeout. Once doing so, the transaction will be maintained and the locks will not be released.
> This might be a deviation from the XA standard but I cannot tell. It seems as if a XA connection does not have a timeout set is active (that is XAResource.start has been called but XAResource.end has not) and the connection gets closed, the XA transaction should be rolled back implicitly. This is being done if the XAResource has a timeout set so it seems that it would not be too hard to do in this case either.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira