[
https://issues.apache.org/jira/browse/GERONIMO-6372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13410405#comment-13410405
]
Gary Tully commented on GERONIMO-6372:
--------------------------------------
The bean in the camel context that initiates recovery is defined as:
{code}<bean id=".." class="org.apache.activemq.pool.ActiveMQResourceManager"
init-method="recoverResource">
<property name="transactionManager" ref="recoverableTxManager" />
<property name="connectionFactory" ref="AmqXaCF" />
<property name="resourceName" value="activemq.external2" />
</bean>{code}
> 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
> 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
