Long-Lived Transactions and Sagas

As explained previously, achieving complete isolation between transactions is relatively expensive.

The system either has to maintain locks for each transaction and potentially block other concurrent transactions from making progress, or abort some transactions to maintain safety, which leads to some wasted effort.

Furthermore, the longer the duration of a transaction is the bigger the impact of these mechanisms is expected to be on the overall throughput.

There is also a positive feedback cycle: using these mechanisms can cause transactions to take longer, which can increase the impact of these mechanisms.

Long-lived transactions

There is a specific class of transactions, called long-lived transactions (LLT).

These are transactions that by their nature have a longer duration in the order of hours or even days, instead of milliseconds. This can happen because this transaction processes a large amount of data, requires human input to proceed, or needs to communicate with third party systems that are slow.

Examples of LLTs

• Batch jobs that calculate reports over big datasets
• Claims at an insurance company, containing various stages that require human input
• An online order of a product that spans several days from order to delivery

As a result, running these transactions using the common concurrent mechanisms degrades performance significantly, since they need to hold resources for long periods of time, while not operating on them.

Sometimes, long-lived transactions do not really require full isolation between each other, but they still need to be atomic, so that consistency is maintained under partial failures. Thus, researchers came up with a new concept: the sagaH. Garcia-Molina and K. Salem, “Sagas,” Proceedings of the 1987 ACM SIGMOD International Conference on Management of Data, 1987..

Saga

The saga is a sequence of transactions $T_1$, $T_2$, …, $T_N$ that can be interleaved with other transactions.

However, it’s guaranteed that either all of the transactions will succeed, or none of them will, maintaining the atomicity guarantee.

Each transaction $T_i$ is associated with a so-called compensating transaction $C_i$, that is executed in case a rollback is needed.