The most relevant example from circulation is when the item status is changed as part of circulation processes.
Updating item status during check out and check in
Typically, when an item is checked out, a loan is created within circulation and the item status in inventory is changed to checked out. If one of these operations fails, the other should be undone, which likely means the item status should be done first as it is likely easier to reverse.
Similarly, when checking in an item, a loan could be closed, and the item status is likely to change, either to available or a request fulfilment related status.
This could get more complicated when there are other side effects applied from these changes, for example, loan action history or item status history.
Other possible examples
- Creating instances via data import
What do we mean by distributed transactions
With the example above, it is relatively apparent that there are changes which need coordinating across contexts (circulation and inventory).
As FOLIO uses distributed business logic and storage modules, we could also consider any operation that involves more than one record (maybe of the same type, maybe of different types) as a distributed transaction, even though these changes are in the same context.
Using an example from above, during a check in, a loan might be closed and request fulfilment might start. It might be that both of these operations need to be reversed if one fails (it might also be that repeating the process is acceptable).