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