servicecomb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <willem.ji...@gmail.com>
Subject Re: [Discussion] compatible TCC support in Saga
Date Tue, 03 Apr 2018 07:47:19 GMT
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 <zh.feng@gmail.com> 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 <willem.jiang@gmail.com>:
>
> > 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.ltk@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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message