Hi Willem Jiang, thanks for your reply. I'd like to help listing a FAQ for this project, but for now, I can only provide Qs not As. Here is my Qs (sorry written in Chinese to avoid poor english obscure the meaning):
1. Saga的执行是同步的还是异步的？发起Saga之后，是等所有Sub-transaction都完成才返回，还是立即返回？ 2. Saga是并行还是顺序执行Sub-transaction的？ 3. Saga对于do、compenstation的实现有什么要求？ 4. Saga保证了A、C、I、D中的哪些部分？ 5. Saga可以嵌套吗？ 6. 如何水平扩展Saga Alpha？ 7. Saga omega 处的代码重构时需要注意什么，以保证不会破坏原Saga/还未执行完毕的Saga？ 8. Saga omega 在执行Saga过程中如果中断，那么重启后Saga还会继续执行吗？ 9. 对于@SagaStart，@Compensable注释的方法，对其方法参数有何要求？ Hi Zheng Feng, thanks for your reply, too. I watched Richardson's presentation (https://www.infoq.com/presentations/saga-microservices) and he talked about ACD: A：all sub-transaction are executed OR all are compensated C：local consistency is handled by service. cross-service consistency is handled by application D：durability is handled by local database These definitions are a little different from which defined in traditional transactions (https://en.wikipedia.org/wiki/ACID). So I think even though "traditional transaction" and "distributed transaction" are all called "transactions", but they are different things. Unlike traditional transaction ACID are guaranteed by techs such as JTA, XA. In distributed transactions(Saga, TCC, etc) ACD are guaranteed by service/application code. So this ACID is not that ACID (此ACID非彼ACID), this transaction is not that transaction(此事务非彼事务). I think we can clarify that in the doc. 2018-03-12 18:05 GMT+08:00 Zheng Feng <zh.f...@gmail.com>: > 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 >> -- Daniel Qian
