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 >
