Current logic will send tx event to alpha in every retry periods.
this will make judeging whether a transaction need to be compensated so complex.
because it is difficult for us to judge whether one subtransaction has done all
the retry,we need to count all the retry times, And for the nested
transactions, it looks more complex.
here is my opinion.
1. if retry is used, and you must set a timeout
if a host power down when it is in retring, then the alpha will never know
whether the transaction need to be compensated.
2. only send tx event to alpha one time for the retry mode.
omega check whether it is timeout by itself to prevent retring when the retries
is set to -1.
________________________________
发件人: Willem Jiang <[email protected]>
发送时间: 2018年9月6日 11:21
收件人: [email protected]
主题: Re: About some problems of alpha's compensate way
Current retry logic is a bit complex, I'm thinking to introduce retry
message to simplify the scanner work[1].
For the compensation part, we could leverage the callback of
TxEventService to react the event directly instead of using event
scanner to find out the transaction which need to be compensated.
We could use different table to handle the code and hot data, I
already had some discussion with Cherry Zhao, he may have some
solution already.
[1]https://issues.apache.org/jira/browse/SCB-768
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Wed, Sep 5, 2018 at 6:19 PM fu chengeng <[email protected]> wrote:
>
>
>
> Hey guys,now the compensate way of alpha has some problems.
> 1.the compensate logic for retry scenarios is not perfect, in some place it
> do not considering retry scenarios.
> 2.do one compensation in one event scanner cycle,it mean that if there are
> 1000 aborted event, it will cost at lest 500s to compensate it. And it has
> some bugs like https://github.com/apache/incubator-servicecomb-saga/issues/253
> 3.all hot and cold data are in the same table
>
> i am thinking of refacting it in these ways.
> do all compensation in one event scan cyclem,and considering retry scenarios
> well.
> separete hot data and cold data into different tables.
>
> is there any good ideas?
>
> <http://aka.ms/weboutlook>
