# Saga


![left](./student-guide/diagram/10-SAGA-01-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.