Already a member? Log in

Sign up with your...

or

Sign Up with your email address

Add Tags

Duplicate Tags

Rename Tags

Share This URL With Others!

Save Link

Sign in

Sign Up with your email address

Sign up

By clicking the button, you agree to the Terms & Conditions.

Forgot Password?

Please enter your username below and press the send button.
A password reset link will be sent to you.

If you are unable to access the email address originally associated with your Delicious account, we recommend creating a new account.

URL: http://kellabyte.com/2012/05/30/clarifying-the-saga-pattern/

Clarifying the Saga pattern « kellabyte

As you build more advanced solutions, you may find the need to do collaborative processing that goes across multiple systems. Since failures are normal in these environments, some activities may fail while others succeed, which will yield inconsistent outcomes. There are mechanisms to handle these situations such as coordinated 2-phase commit (distributed transactions), but in the world of higher scale and cloud computing, these options are no longer suitable.

The Saga interaction pattern was designed to handle these failures. A Saga is a distribution of long-living transactions where steps may interleave, each with associated compensating transactions providing a compensation path across databases in the occurrence of a fault that may or may not compensate the entire chain back to the originator.

In the paper written by Hector Garcia-Molina in 1987 where the Saga pattern is introduced, Hector presented two possible implementations. Implemented directly in the DBMS (database management system) along side the transaction coordinator the Saga log and the database transaction log could be merged together. Another implementation could be on top of an existing DBMS using save points.

The original paper intended use within or on top of a database. A Saga is useful in other contexts as well, but this doesn’t change the fact that a Saga is about compensation across systems.

A Saga is a set of rules for routing a job to multiple collaborating parties, and allowing these parties to backtrack and/or take corrective action in the case of failure.

There are frameworks and examples out there using the name Saga that don’t exhibit the properties defined by Hector Garcia-Molina and resemble a state machine or workflow instead of a Saga. A Saga may be built on top of a workflow and a workflow is built on top of a state machine but state machines or workflows are not Sagas.

State Machine

Wikipedia states

Share It With Others!