Re: [Discussion] compatible TCC support in Saga

[Willem Jiang]

Hi Daniel，

I think current solution is checking the credit as a resource to make sure
the amount of transfer is below the credit first in the try phase or the
transaction phase.

After going through the Chris saga talk[1], there are some interesting
pages[2]. I'm highly recommend you to read about it.
There is some countermeasure about how to solve the isolation issue in the
paper.  Maybe we can consider to implement in our project.

[1]
http://microservices.io/microservices/general/2018/03/22/microxchg-sagas.html
[2]http://bit.ly/semantic-acid-ctm



Willem Jiang

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

On Fri, Apr 6, 2018 at 4:40 PM, Daniel Qian  wrote:

> @Eric Lee. As the bank money transferring example you gave, how can a
> developer
> prevent overdrawing problem?
>
> BTW, I think at a certain time point, customer finds out an
> "inconsistency" result is
> quite intuitive, that shouldn't be considered as a problem.
>
> 2018-04-03 16:04 GMT+08:00 Zheng Feng :
> > OK, let's JIRA it at first.
> >
> > 2018-04-03 15:47 GMT+08:00 Willem Jiang :
> >
> >> Hi Feng
> >>
> >> After go through the wiki page of MVCC[1], it looks like we are doing
> the
> >> same thing with the help of database.
> >> Can you  elaborate using the wrapper class with the database driver?
> >> Currently I don't want to interpret the SQL to do this kind of work.
> >>
> >> [1]https://en.wikipedia.org/wiki/Multiversion_concurrency_control
> >>
> >>
> >> Willem Jiang
> >>
> >> Blog: http://willemjiang.blogspot.com (English)
> >>   http://jnn.iteye.com  (Chinese)
> >> Twitter: willemjiang
> >> Weibo: 姜宁willem
> >>
> >> On Tue, Apr 3, 2018 at 11:07 AM, Zheng Feng  wrote:
> >>
> >> > In the term of hiding the temp table, I think we can provide a wrapper
> >> > class with the database driver. And I'm not sure if we are looking for
> >> > something like MVCC ( Multi-Version Concurrency Control ) ?
> >> >
> >> > 2018-04-02 22:54 GMT+08:00 Willem Jiang :
> >> >
> >> > > Chris just gave a talk[1] recently about the countermeasure for data
> >> > > anomalies.
> >> > > It made us to think if we can find a better way to resolve the
> >> isolation
> >> > > issues.
> >> > >
> >> > > It looks like the TCC pattern can prevent the uncommitted states to
> be
> >> > saw
> >> > > by adding the try phases.
> >> > > And this is what current saga solution is missed.  With help of temp
> >> > table
> >> > > to store the status of the try operation, we don't need the
> coordinator
> >> > > handle much unnormal situation.   It could be better if we don't let
> >> the
> >> > > user know about the temp table. But the challenge is how can we hide
> >> the
> >> > > temp table to the user.
> >> > >
> >> > > [1]
> >> > > http://microservices.io/microservices/general/2018/03/
> >> > > 22/microxchg-sagas.html
> >> > >
> >> > >
> >> > >
> >> > > Willem Jiang
> >> > >
> >> > > Blog: http://willemjiang.blogspot.com (English)
> >> > >   http://jnn.iteye.com  (Chinese)
> >> > > Twitter: willemjiang
> >> > > Weibo: 姜宁willem
> >> > >
> >> > > On Mon, Apr 2, 2018 at 5:57 PM, Eric Lee 
> >> wrote:
> >> > >
> >> > > > Hi, all
> >> > > >
> >> > > > As we have discussed the ACID guarantees Saga provides in the
> >> previous
> >> > > > thread[1], it turns out Saga does not provide isolation
> guarantee. To
> >> > > > improve user experience, the business logic using Saga may need to
> >> > > reorder
> >> > > > to make sure the user-sensitive sub-transaction is the last one
> to be
> >> > > > executed. In sceanrios require full ACID support, the
> implementaion
> >> of
> >> > > Saga
> >> > > > may need to be compatible with the TCC[2] pattern with an extra
> try
> >> > > phase.
> >> > > >
> >> > > > Take a transfer application as an example, it contains transfer in
> >> and
> >> > > > transfer out service of two different databases. From the
> customer's
> >> > > view,
> >> > > > the transfer in and transfer out operation is an atomic operation
> >> which
> >> > > > requires both to be executed or nothing executed. However, in the
> >> > middle
> >> > > of
> >> > > > the overall transaction, e.g. the sub transaction of transfer out
> is
> >> > done
> >> > > > and the sub transaction of transfer in is not done yet, if a
> customer
> >> > > > checkouts out his/her balance, it will become weird as the
> balance is
> >> > not
> >> > > > equal. The isolation is corrupted at this moment in Saga.
> >> > > > In TCC,  the isolation could be solved using either the
> reservation
> >> or
> >> > > > compensation which depends on your bussiness logic.
> >> > > > Reservation: In try phase, use a temporal table to store the
> credit
> >> and
> >> > > > transaction context. In commit phase, reduce the balance in the
> >> account
> >> > > and
> >> > > > remove the 

Re: [Discussion] compatible TCC support in Saga

[Daniel Qian]

@Eric Lee. As the bank money transferring example you gave, how can a developer
prevent overdrawing problem?

BTW, I think at a certain time point, customer finds out an
"inconsistency" result is
quite intuitive, that shouldn't be considered as a problem.

2018-04-03 16:04 GMT+08:00 Zheng Feng :
> OK, let's JIRA it at first.
>
> 2018-04-03 15:47 GMT+08:00 Willem Jiang :
>
>> Hi Feng
>>
>> After go through the wiki page of MVCC[1], it looks like we are doing the
>> same thing with the help of database.
>> Can you  elaborate using the wrapper class with the database driver?
>> Currently I don't want to interpret the SQL to do this kind of work.
>>
>> [1]https://en.wikipedia.org/wiki/Multiversion_concurrency_control
>>
>>
>> Willem Jiang
>>
>> Blog: http://willemjiang.blogspot.com (English)
>>   http://jnn.iteye.com  (Chinese)
>> Twitter: willemjiang
>> Weibo: 姜宁willem
>>
>> On Tue, Apr 3, 2018 at 11:07 AM, Zheng Feng  wrote:
>>
>> > In the term of hiding the temp table, I think we can provide a wrapper
>> > class with the database driver. And I'm not sure if we are looking for
>> > something like MVCC ( Multi-Version Concurrency Control ) ?
>> >
>> > 2018-04-02 22:54 GMT+08:00 Willem Jiang :
>> >
>> > > Chris just gave a talk[1] recently about the countermeasure for data
>> > > anomalies.
>> > > It made us to think if we can find a better way to resolve the
>> isolation
>> > > issues.
>> > >
>> > > It looks like the TCC pattern can prevent the uncommitted states to be
>> > saw
>> > > by adding the try phases.
>> > > And this is what current saga solution is missed.  With help of temp
>> > table
>> > > to store the status of the try operation, we don't need the coordinator
>> > > handle much unnormal situation.   It could be better if we don't let
>> the
>> > > user know about the temp table. But the challenge is how can we hide
>> the
>> > > temp table to the user.
>> > >
>> > > [1]
>> > > http://microservices.io/microservices/general/2018/03/
>> > > 22/microxchg-sagas.html
>> > >
>> > >
>> > >
>> > > Willem Jiang
>> > >
>> > > Blog: http://willemjiang.blogspot.com (English)
>> > >   http://jnn.iteye.com  (Chinese)
>> > > Twitter: willemjiang
>> > > Weibo: 姜宁willem
>> > >
>> > > On Mon, Apr 2, 2018 at 5:57 PM, Eric Lee 
>> wrote:
>> > >
>> > > > Hi, all
>> > > >
>> > > > As we have discussed the ACID guarantees Saga provides in the
>> previous
>> > > > thread[1], it turns out Saga does not provide isolation guarantee. To
>> > > > improve user experience, the business logic using Saga may need to
>> > > reorder
>> > > > to make sure the user-sensitive sub-transaction is the last one to be
>> > > > executed. In sceanrios require full ACID support, the implementaion
>> of
>> > > Saga
>> > > > may need to be compatible with the TCC[2] pattern with an extra try
>> > > phase.
>> > > >
>> > > > Take a transfer application as an example, it contains transfer in
>> and
>> > > > transfer out service of two different databases. From the customer's
>> > > view,
>> > > > the transfer in and transfer out operation is an atomic operation
>> which
>> > > > requires both to be executed or nothing executed. However, in the
>> > middle
>> > > of
>> > > > the overall transaction, e.g. the sub transaction of transfer out is
>> > done
>> > > > and the sub transaction of transfer in is not done yet, if a customer
>> > > > checkouts out his/her balance, it will become weird as the balance is
>> > not
>> > > > equal. The isolation is corrupted at this moment in Saga.
>> > > > In TCC,  the isolation could be solved using either the reservation
>> or
>> > > > compensation which depends on your bussiness logic.
>> > > > Reservation: In try phase, use a temporal table to store the credit
>> and
>> > > > transaction context. In commit phase, reduce the balance in the
>> account
>> > > and
>> > > > remove the temporal table. If anything goes wrong, it can execute the
>> > > > cancel method to remove the temporal table. In this way, if the
>> global
>> > > > transaction fails, it will take no effect on the actual table.
>> Besides,
>> > > > when a customer visits his/her balance, we can simply return the
>> value
>> > in
>> > > > the actual table which is the original value before this transaction
>> > > > executed.
>> > > > Compensation: In try phase, use a temporal table to record the
>> > > compensated
>> > > > value and reduce the balance in the account. In commit phase, remove
>> > the
>> > > > temporal table. If anything goes wrong,  it can execute the cancel
>> > method
>> > > > to recover the balance according to the temporal table and remove the
>> > > > temporal table afterward. In this way, when a customer visits his/her
>> > > > balance, we can do simple calculation of the value in actual table
>> and
>> > > > temporal table to return the origianl value before the transaction
>> > > > executed.
>> > > >

Re: [Discussion] compatible TCC support in Saga

[Zheng Feng]

OK, let's JIRA it at first.

2018-04-03 15:47 GMT+08:00 Willem Jiang :

> Hi Feng
>
> After go through the wiki page of MVCC[1], it looks like we are doing the
> same thing with the help of database.
> Can you  elaborate using the wrapper class with the database driver?
> Currently I don't want to interpret the SQL to do this kind of work.
>
> [1]https://en.wikipedia.org/wiki/Multiversion_concurrency_control
>
>
> Willem Jiang
>
> Blog: http://willemjiang.blogspot.com (English)
>   http://jnn.iteye.com  (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Tue, Apr 3, 2018 at 11:07 AM, Zheng Feng  wrote:
>
> > In the term of hiding the temp table, I think we can provide a wrapper
> > class with the database driver. And I'm not sure if we are looking for
> > something like MVCC ( Multi-Version Concurrency Control ) ?
> >
> > 2018-04-02 22:54 GMT+08:00 Willem Jiang :
> >
> > > Chris just gave a talk[1] recently about the countermeasure for data
> > > anomalies.
> > > It made us to think if we can find a better way to resolve the
> isolation
> > > issues.
> > >
> > > It looks like the TCC pattern can prevent the uncommitted states to be
> > saw
> > > by adding the try phases.
> > > And this is what current saga solution is missed.  With help of temp
> > table
> > > to store the status of the try operation, we don't need the coordinator
> > > handle much unnormal situation.   It could be better if we don't let
> the
> > > user know about the temp table. But the challenge is how can we hide
> the
> > > temp table to the user.
> > >
> > > [1]
> > > http://microservices.io/microservices/general/2018/03/
> > > 22/microxchg-sagas.html
> > >
> > >
> > >
> > > Willem Jiang
> > >
> > > Blog: http://willemjiang.blogspot.com (English)
> > >   http://jnn.iteye.com  (Chinese)
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Mon, Apr 2, 2018 at 5:57 PM, Eric Lee 
> wrote:
> > >
> > > > Hi, all
> > > >
> > > > As we have discussed the ACID guarantees Saga provides in the
> previous
> > > > thread[1], it turns out Saga does not provide isolation guarantee. To
> > > > improve user experience, the business logic using Saga may need to
> > > reorder
> > > > to make sure the user-sensitive sub-transaction is the last one to be
> > > > executed. In sceanrios require full ACID support, the implementaion
> of
> > > Saga
> > > > may need to be compatible with the TCC[2] pattern with an extra try
> > > phase.
> > > >
> > > > Take a transfer application as an example, it contains transfer in
> and
> > > > transfer out service of two different databases. From the customer's
> > > view,
> > > > the transfer in and transfer out operation is an atomic operation
> which
> > > > requires both to be executed or nothing executed. However, in the
> > middle
> > > of
> > > > the overall transaction, e.g. the sub transaction of transfer out is
> > done
> > > > and the sub transaction of transfer in is not done yet, if a customer
> > > > checkouts out his/her balance, it will become weird as the balance is
> > not
> > > > equal. The isolation is corrupted at this moment in Saga.
> > > > In TCC,  the isolation could be solved using either the reservation
> or
> > > > compensation which depends on your bussiness logic.
> > > > Reservation: In try phase, use a temporal table to store the credit
> and
> > > > transaction context. In commit phase, reduce the balance in the
> account
> > > and
> > > > remove the temporal table. If anything goes wrong, it can execute the
> > > > cancel method to remove the temporal table. In this way, if the
> global
> > > > transaction fails, it will take no effect on the actual table.
> Besides,
> > > > when a customer visits his/her balance, we can simply return the
> value
> > in
> > > > the actual table which is the original value before this transaction
> > > > executed.
> > > > Compensation: In try phase, use a temporal table to record the
> > > compensated
> > > > value and reduce the balance in the account. In commit phase, remove
> > the
> > > > temporal table. If anything goes wrong,  it can execute the cancel
> > method
> > > > to recover the balance according to the temporal table and remove the
> > > > temporal table afterward. In this way, when a customer visits his/her
> > > > balance, we can do simple calculation of the value in actual table
> and
> > > > temporal table to return the origianl value before the transaction
> > > > executed.
> > > >
> > > > Within transaction ids in the table row, each create/update/delete
> > > > operation is idempotent and it simplies a lot of work to make sure
> > > > sub-transactions are idempotent.
> > > >
> > > >
> > > > Any other ideas or suggestions on the isolation support in Saga are
> > > > welcome. Thanks.
> > > >
> > > >
> > > > [1] https://lists.apache.org/list.html?dev@servicecomb.apach
> > > > 

Re: [Discussion] compatible TCC support in Saga

[Willem Jiang]

Hi Feng

After go through the wiki page of MVCC[1], it looks like we are doing the
same thing with the help of database.
Can you  elaborate using the wrapper class with the database driver?
Currently I don't want to interpret the SQL to do this kind of work.

[1]https://en.wikipedia.org/wiki/Multiversion_concurrency_control


Willem Jiang

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

On Tue, Apr 3, 2018 at 11:07 AM, Zheng Feng  wrote:

> In the term of hiding the temp table, I think we can provide a wrapper
> class with the database driver. And I'm not sure if we are looking for
> something like MVCC ( Multi-Version Concurrency Control ) ?
>
> 2018-04-02 22:54 GMT+08:00 Willem Jiang :
>
> > Chris just gave a talk[1] recently about the countermeasure for data
> > anomalies.
> > It made us to think if we can find a better way to resolve the isolation
> > issues.
> >
> > It looks like the TCC pattern can prevent the uncommitted states to be
> saw
> > by adding the try phases.
> > And this is what current saga solution is missed.  With help of temp
> table
> > to store the status of the try operation, we don't need the coordinator
> > handle much unnormal situation.   It could be better if we don't let the
> > user know about the temp table. But the challenge is how can we hide the
> > temp table to the user.
> >
> > [1]
> > http://microservices.io/microservices/general/2018/03/
> > 22/microxchg-sagas.html
> >
> >
> >
> > Willem Jiang
> >
> > Blog: http://willemjiang.blogspot.com (English)
> >   http://jnn.iteye.com  (Chinese)
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Mon, Apr 2, 2018 at 5:57 PM, Eric Lee  wrote:
> >
> > > Hi, all
> > >
> > > As we have discussed the ACID guarantees Saga provides in the previous
> > > thread[1], it turns out Saga does not provide isolation guarantee. To
> > > improve user experience, the business logic using Saga may need to
> > reorder
> > > to make sure the user-sensitive sub-transaction is the last one to be
> > > executed. In sceanrios require full ACID support, the implementaion of
> > Saga
> > > may need to be compatible with the TCC[2] pattern with an extra try
> > phase.
> > >
> > > Take a transfer application as an example, it contains transfer in and
> > > transfer out service of two different databases. From the customer's
> > view,
> > > the transfer in and transfer out operation is an atomic operation which
> > > requires both to be executed or nothing executed. However, in the
> middle
> > of
> > > the overall transaction, e.g. the sub transaction of transfer out is
> done
> > > and the sub transaction of transfer in is not done yet, if a customer
> > > checkouts out his/her balance, it will become weird as the balance is
> not
> > > equal. The isolation is corrupted at this moment in Saga.
> > > In TCC,  the isolation could be solved using either the reservation or
> > > compensation which depends on your bussiness logic.
> > > Reservation: In try phase, use a temporal table to store the credit and
> > > transaction context. In commit phase, reduce the balance in the account
> > and
> > > remove the temporal table. If anything goes wrong, it can execute the
> > > cancel method to remove the temporal table. In this way, if the global
> > > transaction fails, it will take no effect on the actual table. Besides,
> > > when a customer visits his/her balance, we can simply return the value
> in
> > > the actual table which is the original value before this transaction
> > > executed.
> > > Compensation: In try phase, use a temporal table to record the
> > compensated
> > > value and reduce the balance in the account. In commit phase, remove
> the
> > > temporal table. If anything goes wrong,  it can execute the cancel
> method
> > > to recover the balance according to the temporal table and remove the
> > > temporal table afterward. In this way, when a customer visits his/her
> > > balance, we can do simple calculation of the value in actual table and
> > > temporal table to return the origianl value before the transaction
> > > executed.
> > >
> > > Within transaction ids in the table row, each create/update/delete
> > > operation is idempotent and it simplies a lot of work to make sure
> > > sub-transactions are idempotent.
> > >
> > >
> > > Any other ideas or suggestions on the isolation support in Saga are
> > > welcome. Thanks.
> > >
> > >
> > > [1] https://lists.apache.org/list.html?dev@servicecomb.apach
> > > e.org:lte=1M:a%20question%20about%20acid%20
> > > [2] http://design.inf.usi.ch/sites/default/files/biblio/rest-tcc.pdf
> > >
> > >
> > > Best Regards!
> > > Eric Lee
> > >
> >
>

?????? [Discussion] compatible TCC support in Saga

[bismy]

Agree with you. Temp table state relates to transaction resource(e.g. database 
table updates), and the coordinator know nothing about them. Developers must 
update temp table based on 
business logic. May be we can find a way for users to easily access temp table. 
And we can provide a fail fast policy when accessing reserved resource to 
improve performance. 


--  --
??: "willem.jiang"<willem.ji...@gmail.com>;
: 2018??4??2??(??) 10:54
??: "dev"<dev@servicecomb.apache.org>;

????: Re: [Discussion] compatible TCC support in Saga



Chris just gave a talk[1] recently about the countermeasure for data
anomalies.
It made us to think if we can find a better way to resolve the isolation
issues.

It looks like the TCC pattern can prevent the uncommitted states to be saw
by adding the try phases.
And this is what current saga solution is missed.  With help of temp table
to store the status of the try operation, we don't need the coordinator
handle much unnormal situation.   It could be better if we don't let the
user know about the temp table. But the challenge is how can we hide the
temp table to the user.

[1]
http://microservices.io/microservices/general/2018/03/22/microxchg-sagas.html



Willem Jiang

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

On Mon, Apr 2, 2018 at 5:57 PM, Eric Lee <eric.lee@gmail.com> wrote:

> Hi, all
>
> As we have discussed the ACID guarantees Saga provides in the previous
> thread[1], it turns out Saga does not provide isolation guarantee. To
> improve user experience, the business logic using Saga may need to reorder
> to make sure the user-sensitive sub-transaction is the last one to be
> executed. In sceanrios require full ACID support, the implementaion of Saga
> may need to be compatible with the TCC[2] pattern with an extra try phase.
>
> Take a transfer application as an example, it contains transfer in and
> transfer out service of two different databases. From the customer's view,
> the transfer in and transfer out operation is an atomic operation which
> requires both to be executed or nothing executed. However, in the middle of
> the overall transaction, e.g. the sub transaction of transfer out is done
> and the sub transaction of transfer in is not done yet, if a customer
> checkouts out his/her balance, it will become weird as the balance is not
> equal. The isolation is corrupted at this moment in Saga.
> In TCC,  the isolation could be solved using either the reservation or
> compensation which depends on your bussiness logic.
> Reservation: In try phase, use a temporal table to store the credit and
> transaction context. In commit phase, reduce the balance in the account and
> remove the temporal table. If anything goes wrong, it can execute the
> cancel method to remove the temporal table. In this way, if the global
> transaction fails, it will take no effect on the actual table. Besides,
> when a customer visits his/her balance, we can simply return the value in
> the actual table which is the original value before this transaction
> executed.
> Compensation: In try phase, use a temporal table to record the compensated
> value and reduce the balance in the account. In commit phase, remove the
> temporal table. If anything goes wrong,  it can execute the cancel method
> to recover the balance according to the temporal table and remove the
> temporal table afterward. In this way, when a customer visits his/her
> balance, we can do simple calculation of the value in actual table and
> temporal table to return the origianl value before the transaction
> executed.
>
> Within transaction ids in the table row, each create/update/delete
> operation is idempotent and it simplies a lot of work to make sure
> sub-transactions are idempotent.
>
>
> Any other ideas or suggestions on the isolation support in Saga are
> welcome. Thanks.
>
>
> [1] https://lists.apache.org/list.html?dev@servicecomb.apach
> e.org:lte=1M:a%20question%20about%20acid%20
> [2] http://design.inf.usi.ch/sites/default/files/biblio/rest-tcc.pdf
>
>
> Best Regards!
> Eric Lee
>

Re: [Discussion] compatible TCC support in Saga

[Willem Jiang]

Chris just gave a talk[1] recently about the countermeasure for data
anomalies.
It made us to think if we can find a better way to resolve the isolation
issues.

It looks like the TCC pattern can prevent the uncommitted states to be saw
by adding the try phases.
And this is what current saga solution is missed.  With help of temp table
to store the status of the try operation, we don't need the coordinator
handle much unnormal situation.   It could be better if we don't let the
user know about the temp table. But the challenge is how can we hide the
temp table to the user.

[1]
http://microservices.io/microservices/general/2018/03/22/microxchg-sagas.html



Willem Jiang

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

On Mon, Apr 2, 2018 at 5:57 PM, Eric Lee  wrote:

> Hi, all
>
> As we have discussed the ACID guarantees Saga provides in the previous
> thread[1], it turns out Saga does not provide isolation guarantee. To
> improve user experience, the business logic using Saga may need to reorder
> to make sure the user-sensitive sub-transaction is the last one to be
> executed. In sceanrios require full ACID support, the implementaion of Saga
> may need to be compatible with the TCC[2] pattern with an extra try phase.
>
> Take a transfer application as an example, it contains transfer in and
> transfer out service of two different databases. From the customer's view,
> the transfer in and transfer out operation is an atomic operation which
> requires both to be executed or nothing executed. However, in the middle of
> the overall transaction, e.g. the sub transaction of transfer out is done
> and the sub transaction of transfer in is not done yet, if a customer
> checkouts out his/her balance, it will become weird as the balance is not
> equal. The isolation is corrupted at this moment in Saga.
> In TCC,  the isolation could be solved using either the reservation or
> compensation which depends on your bussiness logic.
> Reservation: In try phase, use a temporal table to store the credit and
> transaction context. In commit phase, reduce the balance in the account and
> remove the temporal table. If anything goes wrong, it can execute the
> cancel method to remove the temporal table. In this way, if the global
> transaction fails, it will take no effect on the actual table. Besides,
> when a customer visits his/her balance, we can simply return the value in
> the actual table which is the original value before this transaction
> executed.
> Compensation: In try phase, use a temporal table to record the compensated
> value and reduce the balance in the account. In commit phase, remove the
> temporal table. If anything goes wrong,  it can execute the cancel method
> to recover the balance according to the temporal table and remove the
> temporal table afterward. In this way, when a customer visits his/her
> balance, we can do simple calculation of the value in actual table and
> temporal table to return the origianl value before the transaction
> executed.
>
> Within transaction ids in the table row, each create/update/delete
> operation is idempotent and it simplies a lot of work to make sure
> sub-transactions are idempotent.
>
>
> Any other ideas or suggestions on the isolation support in Saga are
> welcome. Thanks.
>
>
> [1] https://lists.apache.org/list.html?dev@servicecomb.apach
> e.org:lte=1M:a%20question%20about%20acid%20
> [2] http://design.inf.usi.ch/sites/default/files/biblio/rest-tcc.pdf
>
>
> Best Regards!
> Eric Lee
>

[Discussion] compatible TCC support in Saga

[Eric Lee]

Hi, all

As we have discussed the ACID guarantees Saga provides in the previous
thread[1], it turns out Saga does not provide isolation guarantee. To
improve user experience, the business logic using Saga may need to reorder
to make sure the user-sensitive sub-transaction is the last one to be
executed. In sceanrios require full ACID support, the implementaion of Saga
may need to be compatible with the TCC[2] pattern with an extra try phase.

Take a transfer application as an example, it contains transfer in and
transfer out service of two different databases. From the customer's view,
the transfer in and transfer out operation is an atomic operation which
requires both to be executed or nothing executed. However, in the middle of
the overall transaction, e.g. the sub transaction of transfer out is done
and the sub transaction of transfer in is not done yet, if a customer
checkouts out his/her balance, it will become weird as the balance is not
equal. The isolation is corrupted at this moment in Saga.
In TCC,  the isolation could be solved using either the reservation or
compensation which depends on your bussiness logic.
Reservation: In try phase, use a temporal table to store the credit and
transaction context. In commit phase, reduce the balance in the account and
remove the temporal table. If anything goes wrong, it can execute the
cancel method to remove the temporal table. In this way, if the global
transaction fails, it will take no effect on the actual table. Besides,
when a customer visits his/her balance, we can simply return the value in
the actual table which is the original value before this transaction
executed.
Compensation: In try phase, use a temporal table to record the compensated
value and reduce the balance in the account. In commit phase, remove the
temporal table. If anything goes wrong,  it can execute the cancel method
to recover the balance according to the temporal table and remove the
temporal table afterward. In this way, when a customer visits his/her
balance, we can do simple calculation of the value in actual table and
temporal table to return the origianl value before the transaction
executed.

Within transaction ids in the table row, each create/update/delete
operation is idempotent and it simplies a lot of work to make sure
sub-transactions are idempotent.


Any other ideas or suggestions on the isolation support in Saga are
welcome. Thanks.


[1] https://lists.apache.org/list.html?dev@servicecomb.apach
e.org:lte=1M:a%20question%20about%20acid%20
[2] http://design.inf.usi.ch/sites/default/files/biblio/rest-tcc.pdf


Best Regards!
Eric Lee