The iterator-based approach that
XAResourceRecovery uses needs to be implemented with the ability to manage states. This leads to unnecessary complexity. In JBoss Transaction Service, you can provide an implementation of the public interface, as below:
public boolean initialise(String p) throws Exception;
public XAResource getXAResources() throws Exception;
During each recovery sweep, the
getXAResources method is called, and attempts recovery on each element of the array. For the majority of resource managers, you only need one
XAResource in the array, since the
recover method can return multiple Xids.
Unlike instances of
XAResourceRecovery instances, which are configured via the XML properties file and instantiated by JBoss Transaction Service, instances of
XAResourceRecoveryHelper are constructed by the application code and registered with JBoss Transaction Service by calling
initialize method is not currently called by JBoss Transaction Service, but is provided to allow for the addition of further configuration options in later releases.
You can deregister
XAResourceRecoveryHelper instances, after which they will no longer be called by the recovery manager. Deregistration may block for a while, if a recovery scan is in progress.
The ability to dynamically add and remove instances of
XAResourceRecoveryHelper while the system is running is beneficial for environments where datasources may be deployed or undeployed, such as application servers. Be careful when classloading behavior in these cases.