From dev-return-4654-archive-asf-public=cust-asf.ponee.io@servicecomb.apache.org Wed Jun 6 09:51:24 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id D4816180671 for ; Wed, 6 Jun 2018 09:51:23 +0200 (CEST) Received: (qmail 16258 invoked by uid 500); 6 Jun 2018 07:51:23 -0000 Mailing-List: contact dev-help@servicecomb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@servicecomb.apache.org Delivered-To: mailing list dev@servicecomb.apache.org Received: (qmail 16247 invoked by uid 99); 6 Jun 2018 07:51:22 -0000 Received: from ui-eu-01.ponee.io (HELO localhost) (176.9.59.70) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Jun 2018 07:51:22 +0000 References: Content-Type: text/plain; charset=utf-8 From: Liang Zhang Message-ID: Subject: Re: Discuss for integrate with saga and sharding-sphere x-ponymail-agent: PonyMail Composer/0.3 In-Reply-To: MIME-Version: 1.0 X-Mailer: LuaSocket 3.0-rc1 To: x-ponymail-sender: f70cbdeed90b5f72edf20ca2dfc019278ac65d90 Date: Wed, 06 Jun 2018 07:51:21 -0000 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 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, zhangliang@apache.org < > zhangliang@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 > > >