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] [Created] (GERONIMO-6372) RecoveryImpl completing in-progress transactions, XidFactoryImpl needs to be smarter with matching
Date Tue, 10 Jul 2012 14:25:34 GMT
Gary Tully created GERONIMO-6372:
------------------------------------

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


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