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

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.2
• Component/s: transaction manager
• Security Level: public (Regular issues)

Environment

Aries, OSGI, camel, activemq

• Patch Info: Patch Available
• Assignee: Guillaume Nodet
• Reporter: Gary Tully
• Created: 10/Jul/12 14:25
• Updated: 24/Jul/12 12:55
• Resolved: 24/Jul/12 12:55

Description

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.

Issue Links

• relates to: ARIES-880 When recovering transactions, only recover old branches to avoid rollback of in-progress transactions