@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 <zh.f...@gmail.com>:
> OK, let's JIRA it at first.
>
> 2018-04-03 15:47 GMT+08:00 Willem Jiang <willem.ji...@gmail.com>:
>
>> 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.f...@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.ji...@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....@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
>> > > >
>> > >
>> >
>>



-- 



Daniel Qian

Reply via email to