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 <willem.ji...@gmail.com> 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 <zh.f...@gmail.com> 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 <willem.ji...@gmail.com> 于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 >>>
