[jira] [Updated] (GERONIMO-6372) RecoveryImpl completing in-progress transactions, XidFactoryImpl needs to be smarter with matching

["Gary Tully (JIRA)" <ji...@apache.org>]

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

Gary Tully updated GERONIMO-6372:
---------------------------------

    Attachment: GERONIMO-6372.patch

Patch that modifies XidFactoryImpl to key the sequence id from current time.
It modifies the branch and globalid match to ignore new xids, ids created sense the start of the XidFactory.
Additional unit test that verifies the new matching rules.
A bunch of recovery tests that depended on an existing factory matching xids after a recovery replay were modified to reinitialize the XidFactory before recovery to simulate a restart.
                
> 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
>         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