Robert Klemme commented on JBTM-353:
I also wonder whether there is a more "compatible" way to handle recovery. What
I mean is this: currently a JCA connector has to make its XAResources either Serializable
or implement XAResourceRecovery. It seems this would somewhat limit compatibility because
a plain JCA standard connector obviously does not come with either of these
Now, if we assume that the XAResource of a JCA connection has access to *all* recovery
information in the EIS (and this is the point where I am unsure whether this is a valid
assumption) then any JCA connection to the same instance would suffice and could be used
for recovery. In that case, basically the information contained in XYZ-ds.xml would be
sufficient to open a connection and do recovery via its XAResource.
To make this more robust an additional flag could be added to the datasource XML
indicating whether this JCA connection is capable of recovering across connections. So
recovery via a newly created connection would only be attempted if the flag was set to
true. Otherwise current behavior (using XAResourceRecovery) would be retained.
XAResourceRecovery has wrong conceptual model
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 4.3.0.GA
Reporter: Jonathan Halliday
Assigned To: Jonathan Halliday
Fix For: 4.4.CR1
XAResourceRecovery is based on an iterator model:
public boolean initialise (String p) throws SQLException;
public boolean hasMoreResources ();
public XAResource getXAResource () throws SQLException;
However, XAResourceRecovery instances are created once at recovery manager startup. This
means there is only ever one recovery pass that actually returns resources. On later
passes the iterator is exhausted and returns nothing. This is the wrong model. XAResources
are not individual entities in need of recovery. Rather they are entities from which a
list of Xids in need of recovery can be retrieved. If the configuration of the underlying
system does not change, the set of XAResources should remain constant over time, being one
per known resource manager. On each recovery pass the list of in-doubt Xids returned by a
recover scan on that resource many change.
The model should change to follow that used by JCA ResourceAdapter:
public XAResource getXAResources()
The recovery pass would then obtain and walk the array rather than using the current
Additionally the exception types should be more generic. SQLException assumes the
resource manager is a db, which may not be the case.
This will also impact the recovery examples, which implement this interface.
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see: http://www.atlassian.com/software/jira