Atomic Service Transaction (Erl)
How can a transaction with rollback capability be propagated across messaging-based services?
When runtime activities that span multiple services fail, the parent business task is incomplete and actions performed and changes made up to that point may compromise the integrity of the underlying solution and architecture.
Runtime service activities can be wrapped in a transaction with rollback feature that resets all actions and changes if the parent business task cannot be successfully completed.
A transaction management system is made part of the inventory architecture and then used by those service compositions that require rollback features.
Transacted service activities can consume more memory because of the requirement for each service to preserve its original state until it is notified to rollback or commit its changes.
As per the previous figure, Services A and B complete their respective tasks successfully. However each time they do, they initiate a local transaction, temporarily saving the current state of the database prior to making their changes (1, 2). After Service C fails its database update attempt (3), Services A and B restore their databases back to their original states (4, 5). The business task is effectively reset or rolled back across services within the pre-defined transaction boundary.