Ondrej Chaloupka created WFLY-13516:
---------------------------------------
Summary: Create integration test scenario for transaction recovery failure of
ejb remoting JBEAP-19408
Key: WFLY-13516
URL:
https://issues.redhat.com/browse/WFLY-13516
Project: WildFly
Issue Type: Task
Components: Test Suite, Transactions
Affects Versions: 20.0.0.Beta1
Reporter: Ondrej Chaloupka
Assignee: Ondrej Chaloupka
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
--
This message was sent by Atlassian Jira
(v7.13.8#713008)