Well, that could be an interesting question. I think it depends on how you define what is "all or nothing". For a example of booking which is often used in the Saga transaction. The request of the user is that "WE HAVE TO BOOKING A FLIGHT PEK-SHA AND TWO NIGHTS IN SHANGHAI HOTEL"
1. Start a Saga transaction 2. booking a flight 3. booking a hotel 4a. ALL bookings are OK ( We get "all") 4b. booking a hotel is failed, we have to compensate to cancel the flight (We get "nothing") 5. End a Saga transaction So from the user's perspective, they get "all or nothing" and from the database it could have something changed ( the status of the flight booking order). And I think this is why the Saga pattern relax the "ISOLATION" attribute from the ACID. I hope it could be helpful for you to understand the Saga transaction. 2018-03-12 16:47 GMT+08:00 Daniel Qian <chanjars...@gmail.com>: > 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[1] for details. In the original saga paper[2], 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[3], 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 [4]. If > > you have any questions or advice for our new architecture, welcome to > point > > them out. > > > > [1] https://www.infoq.com/presentations/saga-microservices > > [2] https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf > > [3] https://en.wikipedia.org/wiki/ACID > > [4] 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 >
