|
As of October 27th, please open all new issues in the Red Hat Customer Portal . |
|
From our initial testing it appears the following snapshot fixes this issue
http://repo.fusesource.com/nexus/content/repositories/snapshots/org/apache/aries/transaction/org.apache.aries.transaction.manager/0.3.1.fuse-7-0-x-SNAPSHOT/org.apache.aries.transaction.manager-0.3.1.fuse-7-0-x-20120709.095949-3.jar fix to Geronimo generation and matching of global and branch xids on: ssh://git@forge.fusesource.com/aries.git
589166a..6b9d299 0.3.1.fuse-7-0-x-stable -> 0.3.1.fuse-7-0-x-stable Fixed by Aries patch. Confirmed by customer.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I think the root cause is a call to recover on the broker. it will return all prepared transactions, irrespective if they were inboubt from recovery or from current in progress transactions.
the TM, sees the xid and does not have a reference to it so it calls rollback. Then the commit fails.
Need to check what is the correct behavior here. I think the Tm should only recover or complete what it knows about, what it knows it has an outcome for. Or the broker needs to filter recovery from in progress in some way.