geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (GERONIMO-6372) RecoveryImpl completing in-progress transactions, XidFactoryImpl needs to be smarter with matching
Date Tue, 10 Jul 2012 14:29:35 GMT

     [ 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

        

Mime
View raw message