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
