Current RecoveryManager’s suspension

At the moment, the suspension of the RecoveryManager (RM) waits for the (running) periodic scan to end. This represents Narayana's last-ditch attempt to recover in-doubt transactions. Once the periodic scan is ended, the `RM` (to be more precise, the `PeriodicRecovery`) enters `SUSPENDED` mode and all in-doubt transactions are left as are in the Object Store. This is based on the assumption that the RM will be resumed and, as a consequence, all in-doubt transactions will be completed.

New proposal

Following a series of issues (linked to this JBTM issue) in WFLY/EAP, a need for a new RM’s suspension has been raised. The requirements are still a bit loose and more info will be added to this issue as the design discussion (that happens here and in all of Narayana's[ communication channels|https://www.narayana.io/community/index.html]) goes forward. So far, the main requirements are:

• When starting the procedure to suspend the RM, new transactions should not be created

• Once the creation of new transactions is no longer possible, the RM waits for the completion of all in-doubt transactions in the Object Store before suspending

Bits and bobs

This section is a collection of suggestions that contributors proposed in different places:

• [Michael] Add property to the RecoveryEnvironmentBean to indicate whether or not suspend should wait for the store to become empty. WildFly would control it via the management model
• And change/add the WildFly transactions subsystem suspend logic to wait until the RecoveryManager suspend call finishes. In the meantime, if the user sets the property to false then periodic recovery will notice after the current pass completes and will return control back to the suspend logic which in turn will return control back to the app server