Hi Zhang Liang, It could be great to integrate the saga and the sharding-sphere. I'm trying to understand the SQL convert and the data snapshot. So I suppose that we have the simple data set just like {id = 1, x = 0} and we have the updateX service to update the X
func updateX ( int x, int i ) { executeSQL("UPDATE x = $x WHERE id = $i", x, i); } T1: T2: saga_start(); saga_start(); updateX(1, 1); updateX(2, 1); call_other_service(); call_other_service(); saga_end(); saga_end(); So after the T1 runs, the snapshot data should be {id = 1, x = 1} and the convertSQL should be "UPDATE x = 0 WHERE id = 1", is it right ? Now we have the other T2 to run after T1, the snapshot data should be {id = 1, x = 2} and convertSQL should be "UPDATE x= 1 WHERE id = 1" ? If the Alpha (Saga coordinator) decides to compensate the T1 when the call_other_service() throws exception, will we call the converSQL to set x = 0 ? Thanks, Zheng Feng 2018-06-06 15:51 GMT+08:00 Liang Zhang <zhangli...@apache.org>: > Hi Willem Jiang, > > I fully agree to keep Omega as simple as possible. > > Sharding-Sphere can ask transaction id from Saga, then save SQL and > snapshot into Sharding-Sphere local db. Saga just as a transaction engine > to determine and notify Sharding-Sphere when to forward(retry) and > backward(compensate). > > Best regrads, > > Zhang Liang > > > On 2018/06/06 06:50:31, Willem Jiang <willem.ji...@gmail.com> wrote: > > 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 > > > > > >