[ https://issues.jboss.org/browse/WFLY-12090?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka edited comment on WFLY-12090 at 5/23/19 8:59 AM: ------------------------------------------------------------------ [~flavia.rainone] thanks for the fix for the WFTC-62. I would like to understand what is the relation of this issue (WFLY-12090) to the WFTC-64? Is it something the customer hits and makes issues? I mean I think the WFTC-64 is not an issue. For the full correct recovery it's expected that the remote server will be restarted with the same object store as it was before plus with the same node id as it has before the failure. * the remote server fails, administrator starts another blank new server at the same address (as WFTC-64 mentions), recovery occurs, WFTC removes the record, administrator realizes he did not port `/data` directory, restarts the server once again with txn records and we have never recovered data here (_this situation expects an error of the administrator_) * the remote server fails, administrator starts another blank new server, recovery occurs, WFTC removes the record, administrator slowly migrates unfinished transactions to the newly started server, those migrated transactions won't be never recovered as the parent EAP node lost the information about them (_we were thinking about such option for the txn recovery management on OpenShift - even this idea was never implemented I think it's still feasible. It would be similar as migration of messages from a killed broker to an active one.) My PoV is that the records should be left untouched for some time (ie. for hours) until they are really deleted. The Narayana has recovery `expiryScanInterval` which defines the time (by default 12h) after which similar records are removed. For the sake of completeness, when remembering correctly these WFTC records - which we are talking about in WFTC-64 - are for orphan detection thus the transaction was defined to be rollback (WFTC-38, WFLY-10201). The records are not necessary if information about participant is saved in the Narayana transaction log and the transaction outcome was defined to be commit. was (Author: ochaloup): [~flavia.rainone] thanks for the fix for the WFTC-62. I would like to understand what is the relation of this issue (WFLY-12090) to the WFTC-64? Is it something the customer hits and makes issues? I mean I think the WFTC-64 is not an issue. For the full correct recovery it's expected that the remote server will be restarted with the same object store as it was before plus with the same node id as it has before the failure. * the remote server fails, administrator starts another blank new server at the same address (as WFTC-64 mentions), recovery occurs, WFTC removes the record, administrator realizes he did not port `/data` directory, restarts the server once again with txn records and we have never recovered data here (_this situation expects an error of the administrator_) * the remote server fails, administrator starts another blank new server, recovery occurs, WFTC removes the record, administrator slowly migrates unfinished transactions to the newly started server, those migrated transactions won't be never recovered as the parent EAP node lost the information about them (_we were thinking about such option for the txn recovery management on OpenShift - even this idea was never implemented I think it's still feasible. It would be similar as migration of messages from a killed broker to an active one.) My PoV is that the records should be left untouched for some time (ie. for hours) until they are really deleted. The Narayana has For the sake of completeness, when remembering correctly these WFTC records - which we are talking about in WFTC-64 - are for orphan detection thus the transaction was defined to be rollback (WFTC-38, WFLY-10201). The records are not necessary if information about participant is saved in the Narayana transaction log and the transaction outcome was defined to be commit. -- This message was sent by Atlassian Jira (v7.12.1#712002)