# Saga (Continue...)


![left](./student-guide/diagram/10-SAGA-02-01.png)




------------------------------------------------------------
saga
In 1987, Princeton University's Hector Garcia-Molina and Kenneth Salem published a Paper Sagas about how to deal with long lived transaction. Saga is a collection of long-lived transaction that can be broken down into subtransactions that can be interleaved. Each of these subtransactions is a real transaction that maintains the consistency of the database.

Saga looks promising to meet our needs. Can all living transaction do this? Here are some restrictions:
- Saga only allows two levels of nesting, top-level Saga and simple subtransactions
- In the outer layer, total atomicity cannot be satisfied. That is, sagas may see partial results from other sagas
- Each subtransaction should be an independent atomic behavior
- In our business scenario, each business environment (such as flight booking, car rental, hotel reservation and payment) is naturally independent, and each transaction can be guaranteed atomic operation with the corresponding service's database.

Saga guarantees ACID the same as TCC:
- Atomicity (Atomicity): Guaranteed under normal circumstances.
- consistency (Consistency) At a certain point in time, the data of Library A and Library B will violate the consistency requirements, but it will eventually be consistent.
- Isolation (Isolation): At a certain point in time, transaction A can read the result submitted by the B transaction part.
- Persistence (Persistence), as with local transaction, data is persisted as long as it is committed.

Today, many distributed transaction solutions and ideas, and middleware products have a shadow of this approach.

Saga is a compensation protocol. In the Saga model, there are multiple participants in a distributed transaction, each participant is a corrective compensation service that requires users to implement their forward and reverse rollback operations according to business scenario.

During the execution of the distributed transaction, the forward operations of each participant are executed in turn, and if all the forward operations are successful, the distributed transaction commits. If any of the forward operations fails, the distributed transaction returns to perform a reverse rollback operation of the previous participants, rolling back the committed participants, and returning the distributed transaction to its original state.