Hi Zhangliang， It's great that you are interesting about the Saga project. Please check out my comments in line.
Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Wed, Jun 6, 2018 at 12:21 PM, zhangli...@apache.org < zhangli...@apache.org> wrote: > Hello servicecomb devs, > > I want discuss for how to integrate with saga and sharding-sphere. > > 1. Split saga as service scope and RDB scope. Service scope still use > annotation to associate compensation method, RDB scope can generate > reverted SQL and data snapshot automatically. Alpha can use revert SQL and > previous data snapshot to compensate automatically, do not need end users > provide additional cancel method. > Current Saga doesn't touch the DB layer, I think we need to do some work on the Omega. Maybe we need to add a common layer handle the common co-ordinate events, and sharding-sphere could do some implementation on the data layer. In this way sharding-sphere could reuse the transaction co-ordinate feature here. BTW, for other who don't know sharding-sphere, you may check out the github project[1] here. [1] https://github.com/sharding-sphere/sharding-sphere > > 2. Sharding-Sphere can generate reverted SQL and data snapshot: > INSERT SQL will revert to DELETE SQL with primary key and sharding key. > UPDATE/DELETE SQL will generate SELECT SQL and save data snapshot first, > and then use UPDATE OR INSERT to compensate data. > Saga may need to change data structure for receive SQL and data snapshot, > maybe use json format to save on payload field is a good idea. I think we need to go through the events structure[2], but if the Omega hold the reference, Alpha just need to send the revert command to Omega. If the Sharding-Sphere can store the SQL and revert SQL into the DB, I don't think Alpha need to know the SQL information. [2] https://github.com/apache/incubator-servicecomb-saga/blob/ce71ab73ae80bc90ba59fe9b038f134fef9426b1/omega/omega-transaction/src/main/java/org/apache/servicecomb/saga/omega/transaction/TxEvent.java > > 3. Sharding-Sphere use guava's eventBus to post DML event. Sharding-Sphere > plan to add 2 listeners, one is just save reverted SQL and snapshot, other > is for send correct info to Omega. > I think we can keep Omega as simple as possible, maybe the event with transaction id could be enough. > > 4. For version of data modification, just guarantee by end user right now, > in future we can consider about use additional version field or shadow > table to handle it. > This is the hardest part which bother me a lot. For the Saga service, we cannot guarantee the data isolation. The user need to do some addition work on the application layer to minimize the side effect. Maybe we should spend some time to check the project omid[3] [3]https://github.com/apache/incubator-omid/ > > Best regards, > Zhang Liang >
