Re: A question about ACID guarantees Saga provides

[Daniel Qian]

@Willem Jiang，多谢。我回头会试试看。

2018-03-14 22:46 GMT+08:00 Willem Jiang :
> 首先应用App启动时候，如果版本信息（应用名 + 版本号）发生变化可以通过Omega通知Alpha。
> 这样就不不会出现版本执行错误的情况。
>
> 对于你举的1.0 升级到 2.0 的情况可能需要通过优雅停机的方式来解决了。
> 因为App 1.0 可能会有多个实例， Alpha在执行回滚的过程中如果只通过Omega来回调的话很难解决实例突然终止的问题，
> 我现在想到的办法是让Alpha直接调用App 1.0提供的恢复服务接口。
> 如果App1.0的服务接口是幂等的且无状态的话，那我们还是能够做到事务的最终一致。
>
>
>
>
> Willem Jiang
>
> Blog: http://willemjiang.blogspot.com (English)
>   http://jnn.iteye.com  (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, Mar 14, 2018 at 9:20 AM, Daniel Qian  wrote:
>
>> Thanks a lot, Willem Jiang, 关于Q7我举个例子来说明我的意思：
>>
>> App version 1.0 里的Saga是这样的：call methodA, call methodB
>> App version 2.0 里的代码是这样的：call methodA, call methodC
>>
>> 把App从1.0 升级到 2.0必定需要将原1.0的App进程停止，然后启动2.0的App进程。
>> 在停止1.0的App进程的时候，可能会出现Saga只执行了一半。
>>
>> 那么启动2.0的App进程之后，会出现以下哪种情况：
>>
>> 1. 1.0 App的未执行完成的Saga永远保持未完成状态
>> 2. 会Saga Alpha会尝试使用2.0App的代码，继续执行未完成Saga
>>
>> 2018-03-13 22:52 GMT+08:00 Willem Jiang :
>> > Hi Dainiel
>> >
>> > Here are my answer to you question， we will write an english version for
>> it
>> > shortly.
>> >
>> > 1. Saga的执行是同步的还是异步的？发起Saga之后，是等所有Sub-transaction都完成才返回，还是立即返回？
>> > 目前Saga事情的执行是同步的，后续我们会提供异步方式的实现。
>> >
>> >
>> > 2. Saga是并行还是顺序执行Sub-transaction的？
>> > Saga pack 是根据调用的代码来决定Saga事件，如果Saga子事件是并行方式调用的， 那Saga协调器也是采用并行方式进行处理的。
>> >
>> > 3. Saga对于do、compenstation的实现有什么要求？
>> > 对服务调用要求是要支持幂等的。
>> >
>> > 4. Saga保证了A、C、I、D中的哪些部分？
>> > 按照前面的回复， Saga 支持 ACD。
>> >
>> > 5. Saga可以嵌套吗？
>> > Saga实现支持子事件嵌套的方式。
>> >
>> > 6. 如何水平扩展Saga Alpha？
>> > Saga Alpha在设计过程中状态信息都存储到数据库，是支持水平扩展的。
>> >
>> > 7. Saga omega 处的代码重构时需要注意什么，以保证不会破坏原Saga/还未执行完毕的Saga？
>> > Saga omega只是通过切面编程的方式获取Saga调用事件，并触发对应的处理流程。
>> > 我不太明白你说的Saga omega处的代码重构是什么意思？解释一下吗？
>> >
>> > 8. Saga omega 在执行Saga过程中如果中断，那么重启后Saga还会继续执行吗？
>> > Saga协调管理的的服务调用如果支持幂等， 调用过程完成后重启Saga协调器 Alpha之后，是可以支持Saga恢复的。
>> >
>> > 9. 对于@SagaStart，@Compensable注释的方法，对其方法参数有何要求？
>> > 因为omega将记录Compensable标注的方法的调用参数来调用Compensable里面提供的补偿方法， 这些参数需要能够序列化。
>> > 目前对于SagaStart没有什么特别的要求，
>> >
>> >
>> > Willem Jiang
>> >
>> > Blog: http://willemjiang.blogspot.com (English)
>> >   http://jnn.iteye.com  (Chinese)
>> > Twitter: willemjiang
>> > Weibo: 姜宁willem
>> >
>> > On Tue, Mar 13, 2018 at 2:33 PM, Daniel Qian 
>> wrote:
>> >
>> >> 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 :
>> >> > 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 

Re: A question about ACID guarantees Saga provides

[Willem Jiang]

首先应用App启动时候，如果版本信息（应用名 + 版本号）发生变化可以通过Omega通知Alpha。
这样就不不会出现版本执行错误的情况。

对于你举的1.0 升级到 2.0 的情况可能需要通过优雅停机的方式来解决了。
因为App 1.0 可能会有多个实例， Alpha在执行回滚的过程中如果只通过Omega来回调的话很难解决实例突然终止的问题，
我现在想到的办法是让Alpha直接调用App 1.0提供的恢复服务接口。
如果App1.0的服务接口是幂等的且无状态的话，那我们还是能够做到事务的最终一致。




Willem Jiang

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

On Wed, Mar 14, 2018 at 9:20 AM, Daniel Qian  wrote:

> Thanks a lot, Willem Jiang, 关于Q7我举个例子来说明我的意思：
>
> App version 1.0 里的Saga是这样的：call methodA, call methodB
> App version 2.0 里的代码是这样的：call methodA, call methodC
>
> 把App从1.0 升级到 2.0必定需要将原1.0的App进程停止，然后启动2.0的App进程。
> 在停止1.0的App进程的时候，可能会出现Saga只执行了一半。
>
> 那么启动2.0的App进程之后，会出现以下哪种情况：
>
> 1. 1.0 App的未执行完成的Saga永远保持未完成状态
> 2. 会Saga Alpha会尝试使用2.0App的代码，继续执行未完成Saga
>
> 2018-03-13 22:52 GMT+08:00 Willem Jiang :
> > Hi Dainiel
> >
> > Here are my answer to you question， we will write an english version for
> it
> > shortly.
> >
> > 1. Saga的执行是同步的还是异步的？发起Saga之后，是等所有Sub-transaction都完成才返回，还是立即返回？
> > 目前Saga事情的执行是同步的，后续我们会提供异步方式的实现。
> >
> >
> > 2. Saga是并行还是顺序执行Sub-transaction的？
> > Saga pack 是根据调用的代码来决定Saga事件，如果Saga子事件是并行方式调用的， 那Saga协调器也是采用并行方式进行处理的。
> >
> > 3. Saga对于do、compenstation的实现有什么要求？
> > 对服务调用要求是要支持幂等的。
> >
> > 4. Saga保证了A、C、I、D中的哪些部分？
> > 按照前面的回复， Saga 支持 ACD。
> >
> > 5. Saga可以嵌套吗？
> > Saga实现支持子事件嵌套的方式。
> >
> > 6. 如何水平扩展Saga Alpha？
> > Saga Alpha在设计过程中状态信息都存储到数据库，是支持水平扩展的。
> >
> > 7. Saga omega 处的代码重构时需要注意什么，以保证不会破坏原Saga/还未执行完毕的Saga？
> > Saga omega只是通过切面编程的方式获取Saga调用事件，并触发对应的处理流程。
> > 我不太明白你说的Saga omega处的代码重构是什么意思？解释一下吗？
> >
> > 8. Saga omega 在执行Saga过程中如果中断，那么重启后Saga还会继续执行吗？
> > Saga协调管理的的服务调用如果支持幂等， 调用过程完成后重启Saga协调器 Alpha之后，是可以支持Saga恢复的。
> >
> > 9. 对于@SagaStart，@Compensable注释的方法，对其方法参数有何要求？
> > 因为omega将记录Compensable标注的方法的调用参数来调用Compensable里面提供的补偿方法， 这些参数需要能够序列化。
> > 目前对于SagaStart没有什么特别的要求，
> >
> >
> > Willem Jiang
> >
> > Blog: http://willemjiang.blogspot.com (English)
> >   http://jnn.iteye.com  (Chinese)
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Tue, Mar 13, 2018 at 2:33 PM, Daniel Qian 
> wrote:
> >
> >> 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 :
> >> > 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 :
> 

Re: A question about ACID guarantees Saga provides

[Daniel Qian]

Thanks a lot, Willem Jiang, 关于Q7我举个例子来说明我的意思：

App version 1.0 里的Saga是这样的：call methodA, call methodB
App version 2.0 里的代码是这样的：call methodA, call methodC

把App从1.0 升级到 2.0必定需要将原1.0的App进程停止，然后启动2.0的App进程。
在停止1.0的App进程的时候，可能会出现Saga只执行了一半。

那么启动2.0的App进程之后，会出现以下哪种情况：

1. 1.0 App的未执行完成的Saga永远保持未完成状态
2. 会Saga Alpha会尝试使用2.0App的代码，继续执行未完成Saga

2018-03-13 22:52 GMT+08:00 Willem Jiang :
> Hi Dainiel
>
> Here are my answer to you question， we will write an english version for it
> shortly.
>
> 1. Saga的执行是同步的还是异步的？发起Saga之后，是等所有Sub-transaction都完成才返回，还是立即返回？
> 目前Saga事情的执行是同步的，后续我们会提供异步方式的实现。
>
>
> 2. Saga是并行还是顺序执行Sub-transaction的？
> Saga pack 是根据调用的代码来决定Saga事件，如果Saga子事件是并行方式调用的， 那Saga协调器也是采用并行方式进行处理的。
>
> 3. Saga对于do、compenstation的实现有什么要求？
> 对服务调用要求是要支持幂等的。
>
> 4. Saga保证了A、C、I、D中的哪些部分？
> 按照前面的回复， Saga 支持 ACD。
>
> 5. Saga可以嵌套吗？
> Saga实现支持子事件嵌套的方式。
>
> 6. 如何水平扩展Saga Alpha？
> Saga Alpha在设计过程中状态信息都存储到数据库，是支持水平扩展的。
>
> 7. Saga omega 处的代码重构时需要注意什么，以保证不会破坏原Saga/还未执行完毕的Saga？
> Saga omega只是通过切面编程的方式获取Saga调用事件，并触发对应的处理流程。
> 我不太明白你说的Saga omega处的代码重构是什么意思？解释一下吗？
>
> 8. Saga omega 在执行Saga过程中如果中断，那么重启后Saga还会继续执行吗？
> Saga协调管理的的服务调用如果支持幂等， 调用过程完成后重启Saga协调器 Alpha之后，是可以支持Saga恢复的。
>
> 9. 对于@SagaStart，@Compensable注释的方法，对其方法参数有何要求？
> 因为omega将记录Compensable标注的方法的调用参数来调用Compensable里面提供的补偿方法， 这些参数需要能够序列化。
> 目前对于SagaStart没有什么特别的要求，
>
>
> Willem Jiang
>
> Blog: http://willemjiang.blogspot.com (English)
>   http://jnn.iteye.com  (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Tue, Mar 13, 2018 at 2:33 PM, Daniel Qian  wrote:
>
>> 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 :
>> > 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 :
>> >
>> >> 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 

Re: A question about ACID guarantees Saga provides

[Daniel Qian]

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 :
> 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 :
>
>> 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 :
>>
>> > 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] 

Re: A question about ACID guarantees Saga provides

[Zheng Feng]

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 :

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

Re: A question about ACID guarantees Saga provides

[Willem Jiang]

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

Re: A question about ACID guarantees Saga provides

[Daniel Qian]

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

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

Re: A question about ACID guarantees Saga provides

[Eric Lee]

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 :

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