Non-Serializable XAResource recovery warning

Sometimes you may see the following:

2008-10-13 21:59:33,681 WARN  [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] Could not find new XAResource to use for recovering non-serializable XAResource < 131075, 28, 26, 1-a0be25a:ca6b:48f3c9af:ba14a0be25a:ca6b:48f3c9af:ba15 >

During the commit phase of the transaction, the coordinator must durably record as much information about each participant as possible to attempt recovery in the event of a failure (coordinator or participants). If XAResources are the participants then as mentioned in the JBossTS documentation we'll just save a serialized instance of the participant and assume that deserializing upon recovery will return an instance that can be used to drive recovery. However, if the XAResource is not serializable (as most are not) then additional information is required (JBossTS does not see the connections from which the original XAResource was returned, so it has no direct way of getting this information). It does this through XAResourceRecovery instances, which are explained in full in the JBossTS documentation, but to summarize: each datasource that returns an XAResource may potentially need an XAResourceRecovery instance.

So when you see this message it means that you had a previous transaction failure involving a non-Serializable XAResource and JBossTS is attempting recovery. Because the resource wasn't Serializable, JBossTS does not have enough information at hand to recover the resource and needs help. You need to provide an instance of a XAResourceRecovery implementation and tie it into the recovery process in order for this to occur. What then happens is that JBossTS will ask your XAResourceRecovery instance for a new XAResource to use during recovery, essentially replacing the old (stale) instance with a new one. For more details, check out the documentation.

Note that it is not mandatory for your XAResource to implement Serializable: it's just a lot easier if it does. However, if this is not the case then please consult the documentation on XAResourceRecovery or ensure that an already provided and applicable instance is configured in the JBossTS configuration file.

It is also worth noting that this warning may happen in the situation where the resource has been successfully committed but a crash then occurs. If the crash happens before the coordinator can update the log, then upon recovery JBossTS will attempt to retry the commit. Eventually JBossTS will assume that the resource committed and ignore it, possibly moving the log to a safe location for later viewing by an administrator or deletion. See the JBossTS documentation on 'assumed complete' rules and configuration options.