servicecomb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zheng Feng <zh.f...@gmail.com>
Subject Re: Discuss for integrate with saga and sharding-sphere
Date Wed, 06 Jun 2018 16:33:10 GMT
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 <zhangliang@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.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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message