There was found a transaction recovery failure scenario which caused regression being filled as https://issues.redhat.com/browse/JBEAP-19408.

The issue JBEAP-19408 causes that in case of WildFly communicating over EJB remoting to other WildFly and when there is a failure then there could be left prepared resources on the other WildFly which are never rolled-back.
E.g. in case of database it means locked rows which could not be manipulated with until administrator comes and manually unlock them.

The scenario which was this hit with and which should be simulated in the WildFly testsuite:

• server A starts the transactions
• transaction at server A enlists the an XAResource related to a future interation with server B (At server A, WFTC enlists an "ejb client resource" related to a future interaction with B)
• server A makes the remote EJB call to server B where transaction is propagated
• server A asks server B to prepare
• server A creates a "ejb client resource" XAResourceRegistry file system record
• server B prepares
• server A crashes before it writes a transaction log
• server A restarts (transaction recovery cycle starts)
• server A can see no record of the transactions in the object store
• server A uses the standard orphan detection processing
• server A calls XAResource.recover(TMSTARTRSCAN) on "ejb client resource". It returns prepared XAResources from server B as there is XAResourceRegistry file system record on server A (related to a future interation with server B)
• server A calls XAResource.recover(TMENDRSCAN), the recovery cycle finishes
• server A calls another round of recovery wwith XAResource.recover(TMSTARTRSCAN) and there is the XAResourceRegistry and orphan detection rolls-back the subtransaction resources on server B