]
Paul Robinson updated JBTM-1639:
--------------------------------
Reporter: Gytis Trikleris (was: Paul Robinson)
Improve XTS Api for looking up Recovery Manager to prevent developer
from poling
--------------------------------------------------------------------------------
Key: JBTM-1639
URL:
https://issues.jboss.org/browse/JBTM-1639
Project: JBoss Transaction Manager
Issue Type: Enhancement
Components: XTS
Reporter: Gytis Trikleris
Assignee: Paul Robinson
Fix For: 6.0.0
Currently the developer needs to poll for the RecoveryManager as it's possible that
the application can be deployed before the XTS subsystem has finished startup.
This issue was worked around in JBTM-1522 and in the TXBridge tests, by having the
application poll until the RM was not null.
Two possible solutions:
Have a blocking call to XTSATRecoveryManager.getRecoveryManager() that doesn't return
until there is an RM available. if we use the existing java method, we need to analyse all
usages to make sure returning null is not a valid outcome.
Another solution is to find out how to delay the application's initialisation until
after XTS has started. This puts the burden on the application developer to implement, but
requires no changes to the XTS code. See JBTM-1522 for alternative mechanisms for
initialising the application. I tried three and none of them fired after the server had
booted.
To Reproduce
Put breakpoints on:
Application's usage of: XTSATRecoveryManager.getRecoveryManager(); //Stop all
threads
XTSATRecoveryManager.setRecoveryManager() // stop on Thread only
Copy your application to the deploy directory (xtstest.war is a good choice). Now start
the server with debugging enabled (suspend=y). To reproduce this you will see the
XTSATRecoveryManager.setRecoveryManager() BP fire, and then shortly after the
XTSATRecoveryManager.getRecoveryManager() BP will fire. Allow the getRecoveryManager to
continue and you will notice it is null. Fix this problem, and the getRecoveryManager will
wait until the setRecoveryManager is complete and thus always return a non-null RM.
Once this is fixed, find all occurrence of the polling work-around and have them use the
solution to this issue.