OK, that makes sense to have such status query interface and this should be introduced by the Java annotations ?
Willem Jiang <[email protected]> 于2018年11月1日周四 下午3:27写道： > Hi Zheng, > > If the Omega failed to send the Saga event to the Alpha, Alpha could > think the transaction is failed and start the compensation process. > In this way we need the Omega provide the query interface for the > Alpha to verify the states of the transaction to avoid this kind of > situation. > > If we let the Omega (transaction initiator) to know about the timeout, > the Omega help Alpha to do more things, as the transaction initiator > Omega knows all the other services invocation status. In this way > Alpha just need to deal with the transaction initiator Omega crash > situation. > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Thu, Nov 1, 2018 at 12:13 PM Zheng Feng <[email protected]> wrote: > > > > +1. I think we had some implementation codes before by using the > Executors. @Willem Jiang can you recall why we move the timeout handle to > the alpha server ? is there any particular reason ? I think maybe the > following > > 1) the omega fails to send the cancel message when timeout happens due > to the network error ? So the compensation will not happen. > > 2) the omega crashes and can not recovery to send the message when it > re-starts ? > > > > Willem Jiang <[email protected]> 于2018年11月1日周四 上午11:24写道： > >> > >> +1 to use the POC show us the fact :) > >> Now I'm thinking to let Omega more smart[1] by doing the timeout > >> monitor itself to reduce the complexity of Alpha. > >> In this way the Alpha just need to store the message and response the > >> request from Omega. > >> > >> [1]https://issues.apache.org/jira/browse/SCB-1000 > >> > >> Willem Jiang > >> > >> Twitter: willemjiang > >> Weibo: 姜宁willem > >> On Thu, Nov 1, 2018 at 11:13 AM 赵俊 <[email protected]> wrote: > >> > > >> > We can write a simple demo to prove reactive or original netty can > improve throughout using omega/alpha architecture > >> > > >> > > >> > > On Nov 1, 2018, at 8:29 AM, Willem Jiang <[email protected]> > wrote: > >> > > > >> > > I thinking to use actor to do the reactive work, but it looks like > we > >> > > could make alpha more simple by implement some logic on the Omega > >> > > side, such as the timeout function. > >> > > > >> > > Willem Jiang > >> > > > >> > > Twitter: willemjiang > >> > > Weibo: 姜宁willem > >> > > > >> > > On Thu, Nov 1, 2018 at 1:57 AM wjm wjm <[email protected]> wrote: > >> > >> > >> > >> async is not enough, better to be reactive. > >> > >> > >> > >> 赵俊 <[email protected]> 于2018年10月31日周三 下午5:07写道： > >> > >> > >> > >>> Hi, Willem > >> > >>> > >> > >>> I think make the last invocation async is limitation for > performance tuning > >> > >>> As block grpc invoking also use async way internal, only blocking > in > >> > >>> futureTask.get(). > >> > >>> > >> > >>> > >> > >>> > >> > >>> > >> > >>>> On Oct 30, 2018, at 4:51 PM, Willem Jiang < > [email protected]> > >> > >>> wrote: > >> > >>>> > >> > >>>> Thanks for feedback, > >> > >>>> I just used one participator to show the most simplest way of > service > >> > >>>> interaction. > >> > >>>> I just add some words about the "initial service" and the > >> > >>>> "participant service". > >> > >>>> > >> > >>>> Now we could think about how to reduce the overheads of the > >> > >>>> distributed transaction. I think we can make the last invocation > >> > >>>> async to speed up the processing, but it could be a challenge > for us > >> > >>>> to leverage the async remote invocation without introduce the > risk of > >> > >>>> losing messages. > >> > >>>> > >> > >>>> Any thoughts? > >> > >>>> > >> > >>>> Willem Jiang > >> > >>>> > >> > >>>> Twitter: willemjiang > >> > >>>> Weibo: 姜宁willem > >> > >>>> On Tue, Oct 30, 2018 at 4:37 PM Zheng Feng <[email protected]> > wrote: > >> > >>>>> > >> > >>>>> Great work ! It could be more clear if you can mark the > invocation > >> > >>> arrows > >> > >>>>> with the step numbers. And it usual has two or more > participants in a > >> > >>>>> distribute transaction. > >> > >>>>> So you need to improve the sequence diagram to show these > actors. > >> > >>>>> > >> > >>>>> It also could be helpful to describe what is the "initial > service" and > >> > >>> the > >> > >>>>> "participant service" ? > >> > >>>>> > >> > >>>>> Willem Jiang <[email protected]> 于2018年10月30日周二 下午4:23写道： > >> > >>>>> > >> > >>>>>> Hi Team, > >> > >>>>>> > >> > >>>>>> I wrote a page[1] to analyze the overheads that Saga or TCC > could > >> > >>>>>> introduce. > >> > >>>>>> Please check it out and let me know what you think. > >> > >>>>>> You can either reply this mail or just add comment on the wiki > page. > >> > >>>>>> > >> > >>>>>> [1] > >> > >>>>>> > >> > >>> > https://cwiki.apache.org/confluence/display/SERVICECOMB/Distributed+Transaction+Coordinator+Overhead > >> > >>>>>> > >> > >>>>>> Willem Jiang > >> > >>>>>> > >> > >>>>>> Twitter: willemjiang > >> > >>>>>> Weibo: 姜宁willem > >> > >>>>>> > >> > >>> > >> > >>> > >> > >
