servicecomb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 赵俊 <zhaoju...@jd.com>
Subject Re: Saga,TCC overhead
Date Wed, 31 Oct 2018 09:06:58 GMT
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.jiang@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.feng@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.jiang@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
>>> 

Mime
View raw message