[
https://issues.jboss.org/browse/JBTM-2183?page=com.atlassian.jira.plugin....
]
Mark Little edited comment on JBTM-2183 at 5/25/14 2:15 PM:
------------------------------------------------------------
Have we seen this behaviour elsewhere in the past? I don't recall it. A change in
Oracle? Or just lucky for us so far not to have seen it?
As to changing the default, we can't do that until the EAP 7 timeframe even if we
wanted to. Plus, we'd better be able to show that this has no impact on performance,
reliability etc. in environments where the RM doesn't exhibit this behaviour.
Otherwise may be best to err on the side of caution and perhaps catch the error in
recovery and swap in the alternate behaviour for the next sweep.
was (Author: marklittle):
Have we seen this behaviour elsewhere in the past? I don't recall it.
As to changing the default, we can't do that until the EAP 7 timeframe.
Need finer grained control over which XAResource is used for
recovery
---------------------------------------------------------------------
Key: JBTM-2183
URL:
https://issues.jboss.org/browse/JBTM-2183
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Recovery
Affects Versions: 4.17.20, 5.0.1
Reporter: Michael Musgrove
Assignee: Michael Musgrove
Fix For: 4.17.21, 5.0.2
During recovery when we recreate an XAResource we need one which knows about the xid that
is being recovered. We implement this in the XARecoveryModule which calls recover() on
each resource returned by registered XA recovery helpers. If the xid returned from recover
matches against the one we are recovering we use that XAResource to drive recovery.
However, some RMs will return all prepared transaction branches and not just the ones
specific to the particular resource we made the recover call on. The scenario that led to
the issue was configuring 2 datasources against the same database but with different
credentials. If we replay the commit on the "wrong" one we get ORA-24774:
"The transaction specified in the call refers to a transaction created by a different
user".
The fix is to return an XA resource that matches the JNDI name we logged in the recovery
record and if the JNDI name is not available we drop back to using the current solution
(note that the name is available when running in wildfly/EAP) .
And finally, I I wonder if we want to make this new behaviour optional?
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)