Hi Daniel

Saga controller need to call the compensation when the transaction failed,
to make sure the whole saga transaction is "all or nothing".

The database doesn't mean saga event log database, and as we don't block
any other database operation, we cannot make sure the database is
unchanged, but the former transaction could be compensated by Saga
controller.

BTW,  Could you help us improve the documents?
We can start from the FAQ which could base on your questions in the mailing
list.



Willem Jiang

Blog: http://willemjiang.blogspot.com (English)
          http://jnn.iteye.com  (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Mar 12, 2018 at 4:47 PM, Daniel Qian <chanjars...@gmail.com> wrote:

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