async is not enough, better to be reactive. 赵俊 <zhaoju...@jd.com> 于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 <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 > >>> > >
