[
https://issues.redhat.com/browse/WFLY-13516?page=com.atlassian.jira.plugi...
]
Ondrej Chaloupka updated WFLY-13516:
------------------------------------
Comment: was deleted
(was: The PR was closed as there is need first to have change of the Narayana filter
priority to something else than the {USER}
(
https://github.com/jbosstm/narayana/blob/5.10.4.Final/rts/at/bridge/src/m...).
The issue is tracked at
https://issues.redhat.com/browse/JBTM-3321.
There is needed the Narayana codebase to be changed and the component upgrade to be placed
in.)
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
Priority: Major
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)