​Thank​s 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

Reply via email to