Agree with Willem’s ideas.

1.alpha do compensation based on transaction end instruction triggered by omega 
instead of using event scanner.
2. about hot and cold event data, here is my opinion.
    - transaction event table. (Hot)
      storage txEvent receiving from omega directly.
    - transaction finished table.(cold)
      When receiving global transaction end instruction.
         - if there does’t exist compensation, move related transaction record 
to finish table asynchronous.
         - if need compensation, when receiving compensation finished command 
from omega, move the related event to finished table asynchronous.



> On 6 Sep 2018, at 11:21 AM, Willem Jiang <[email protected]> wrote:
> 
> 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>

Reply via email to