geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet (JIRA)" <j...@apache.org>
Subject [jira] [Assigned] (GERONIMO-6372) RecoveryImpl completing in-progress transactions, XidFactoryImpl needs to be smarter with matching
Date Tue, 24 Jul 2012 12:17:33 GMT

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

Guillaume Nodet reassigned GERONIMO-6372:
-----------------------------------------

    Assignee: Guillaume Nodet
    
> 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

        

Mime
View raw message