servicecomb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liang Zhang <zhangli...@apache.org>
Subject Re: Discuss for integrate with saga and sharding-sphere
Date Wed, 06 Jun 2018 07:51:21 GMT
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.jiang@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, 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
> >
> 

Mime
View raw message