Sagas

Abstract

Long lived transactions (LLTs) hold on to database resources for relatively long periods of time, slgmficantly delaymg the termmatlon of shorter and more common transactionsTo alleviate these problems we propose the notion of a saga A LLT 1s a saga if it can be written as a sequence of transactions that can be interleaved with other transactionsThe database management system guarantees that either all the transactions m a saga are successfully completed or compensatmg transactions are run to amend a partial execution Both the concept of saga and its lmplementatlon are relatively simple, but they have the potential to improve performance slgmficantlyWe analyze the various lmplementatron issues related to sagas, including how they can be run on an exlstmg system that does not directly support themWe also discuss techniques for database and LLT design that make it feasible to break up LLTs mto sagas

Handling Transactional Properties in Web Service Composition

“…service A must complete its execution before service B can start). In order to take into account such dependencies, we plan to extend the model presented here based on the principles of well-known transactional process models such as Sagas [21], which rely on the compensation capabilities of quasi-atomic services.…”

“…dependencies imposing that a service must fully complete before another one can start). In order to support such control dependencies in the context of a transactional service composition model, techniques from the area of long-running database transactions and transactional business processes (see for example the concept of Sagas [21,12]) would need to be incorporated. Dealing with such issues is outside the scope of this paper and integration in our model of a more complete set of composition operators is left as a direction for future work.…”

Self-adapting recovery nets for policy-driven exception handling in business processes

“…The earliest of the long-running transaction models was the Saga model [18]. A Saga is a chain of transactions that is itself atomic.…”

A Dataflow-Oriented Atomicity and Provenance System for Pipelined Scientific Workflows

“…However, traditional techniques for atomicity in transaction processing systems are inappropriate for complex long-running processes in distributed and heterogeneous environments. Compensation is generally considered as a proper way to handle rollback in business workflows [6], as it can eliminate effects of already committed transactions. The atomicity techniques based on compensation in business workflows [8,5] are not suitable for scientific workflows.…”