Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Date: Tue, 24 Jul 2012 12:56:34 +0000 (UTC)
From: "Guillaume Nodet (JIRA)" <jira@apache.org>
To: dev@geronimo.apache.org
Message-ID: <855563999.95410.1343134594976.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <1984913927.28400.1341930334882.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Resolved] (GERONIMO-6372) RecoveryImpl completing
 in-progress transactions, XidFactoryImpl needs to be smarter with matching
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/GERONIMO-6372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guillaume Nodet resolved GERONIMO-6372.
---------------------------------------

    Resolution: Fixed

Not sure which version I should put. djencks ?
                
> RecoveryImpl completing in-progress transactions, XidFactoryImpl needs to be smarter with matching
> --------------------------------------------------------------------------------------------------
>
>                 Key: GERONIMO-6372
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-6372
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: transaction manager
>    Affects Versions: 2.2
>         Environment: Aries, OSGI, camel, activemq
>            Reporter: Gary Tully
>            Assignee: Guillaume Nodet
>         Attachments: GERONIMO-6372.patch
>
>
> Given a camel route with from("activemq:a").to("activemq:b") in a Geronimo managed XA transaction. On start/restart new transactions are created in parallel with recovery of the jms components.
> There are two issues:
>  * The Recovery processing can match new transactions through the XidFactory.matchXX methods and rollback new work in error. (Note: a xa_recover of activemq correctly returns *all* prepared transactions)
>  * The XidFactoryImpl(byte[] seed) can create duplicate xids which could potentially interfere with recovering transactions and makes it impossible to determine from the logs what is going on.
> Xids should be globally unique and recoverable. So they need a persistent unique seed (provided through configuration) and an ever increasing id.
> The current time provides a simple approach to an increasing id that negates the need to persist the last used id in the transaction recovery log. 
> (It has the downside of regressing if the XidFactory is recreated in the same millisecond, but I think this is in practice improbable outside unit tests.)
> If the id component is keyed of the epoch, a recovering XidFactory can match only old Xids, ones created by it in a previous incarnation. In this way it can avoid completing newly created transactions.

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