Thanks for reply. I'll checkout refs you give. Saga project is really really lack of docs, hope you guys will work on that.
And 1 more question. The wiki says Atomicity: > Atomicity requires that each transaction be **"all or nothing"**: if one part of the transaction fails, then the entire transaction fails, and the database state is left **unchanged**. I think the Saga's do-compensate pattern is not "all or nothing", database is not left "unchanged", there is actually something changed(ie. a canceled order) in database (saga event log database or microservice database). 2018-03-10 10:56 GMT+08:00 Eric Lee <eric.lee....@gmail.com>: > Well, Saga actually provides guarantee of ACD. You can checkout Chris > Richardson's > latest talk of saga for details. In the original saga paper, it > mentions that > > > At the outer level full atomicity is not provided. That is, sagas may > view > > the partial results of other sagas. > > > According to the ACID definition, it shows saga does not provide > isolation guarantee instead of atomicity as all sub transactions within a > global transaction is either done or compensated. > > For each global transaction, it will have both SagaStartedEvent and > SagaEndedEvent while for each sub transaction, it will have TxStartedEvent > and either TxEndedEvent or TxCompensatedEvent. If the global transaction > succeeds, saga guarantees that all sub transactions will have both > TxStartedEvent and TxEndedEvent. If the global transaction fails, saga > guarantees that all completed sub transactions are compensated and hence > have all of TxStartedEvent, TxEndedEvent, TxCompensatedEvent. In this way, > we can guarantee the consistency. > > Besides, the implementation of saga coordinator is stateless, all saga > event logs are stored in persistent storage. In this way, we can guarantee > the durability. > > BTW, we have refactored the saga lately. The architecture in the blog you > saw is outdated. You can checkout its latest implementation from . If > you have any questions or advice for our new architecture, welcome to point > them out. > >  https://www.infoq.com/presentations/saga-microservices >  https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf >  https://en.wikipedia.org/wiki/ACID >  https://github.com/apache/incubator-servicecomb-saga > > > Best Regards! > Eric Lee > > 2018-03-09 15:59 GMT+08:00 Daniel Qian <chanjars...@gmail.com>: > > > Hello guys: > > > > I read the amazing blog "Eventual Data Consistency Solution in > ServiceComb > > - part 2" and I'm kind of confused about these two statements: > > > > > Saga does not provide ACID guarantee, because atomicity and isolation > are > > not satisfied .... > > > > > With durable saga log, saga guarantees consistency and durability > > > > I guess the first statement is talking about how so called "Transaction" > > behaves in **Saga pattern**. > > > > And the second statement is talking about the implementation of Saga's > > state store. But that's a little strange to say "Saga provides C and D > > because it's state store provides C and D". > > > > I think Saga pattern actually does not guarantee either of A, C, I or D. > Am > > I right? > > > > > > -- > > > > > > > > Daniel Qian > > > -- Daniel Qian