Hi Zhao Jun, If the omega didn't send any request to Alpha server, the Alpha server would not send any compensation command to it later because Alpha don't know the crashed participate omega.
Best, Longchun Zhang On Tue, Jan 8, 2019 at 5:33 PM Willem Jiang <willem.ji...@gmail.com> wrote: > FYI, I just created a JIRA[1] to track this issue. > > [1]https://issues.apache.org/jira/browse/SCB-1103 > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Tue, Jan 8, 2019 at 5:19 PM Willem Jiang <willem.ji...@gmail.com> > wrote: > > > > Oh， I just found another sceniro that current ParticipatedEvent cannot > > handle. It's timeout, > > if we don't have the StartedEvent, we cannot tell if the invocation > > is timeout or not. > > > > Willem Jiang > > > > Twitter: willemjiang > > Weibo: 姜宁willem > > > > On Tue, Jan 8, 2019 at 5:00 PM Longchun Zhang <longc...@gmail.com> > wrote: > > > > > > Sure, You are right, I mean the none transaction resource operations. > > > > > > The framework should support most general condition. We can't assume > > > all the micro-service do have local transactions supporting. > > > and sometimes micro-service will leverage DB transaction and other > > > None transaction > > > resource related operations in the same time. > > > > > > As you said We can send a Participate-Start-Event to Alpha > 'Synchronously' > > > before do any business operations, > > > A sub_transaction_id can be generated in the same time and send with > > > Participate-Start-Event to Alpha. > > > Alpha can recorded it and use it in the confirm or cancel phases. and > in > > > the omega side sub_transaction_id should be > > > recorded with every followed business operations in order to cancel or > > > confirm those operations with this id. > > > > > > After the business operation we can send a Participate-End-Event to > Alpha > > > with status 'Asynchronously'. > > > > > > Best, > > > > > > Longchun Zhang > > > > > > > > > > > > > > > On Tue, Jan 8, 2019 at 4:27 PM Willem Jiang <willem.ji...@gmail.com> > wrote: > > > > > > > Hi Longchun, > > > > > > > > Thanks for reporting this issue. The ParticipatedEvent is designed to > > > > track the success transaction which means if the transaction is > > > > failed, we could leverage the local transactional API (Spring > > > > Transactional AOP）to do the clean up work instead of waiting for > Omega > > > > invoke cancel method. > > > > You may argue what if there are some other resource allocation in the > > > > try method and it cannot be cleaned even with the @Tranactional > > > > annotation. I think we could consider to add ParticipateStartedEvent > > > > and ParticipateEndedEvent to fix this kind of problem. > > > > > > > > Any thoughts on this? > > > > > > > > Willem Jiang > > > > > > > > Twitter: willemjiang > > > > Weibo: 姜宁willem > > > > > > > > On Tue, Jan 8, 2019 at 3:58 PM Longchun Zhang <longc...@gmail.com> > wrote: > > > > > > > > > > Hi guys, > > > > > > > > > > > > > > > > > > > > Recently I am reading the TCC implementation. > > > > > > > > > > > > > > > > > > > > Current implementation is: In the try phase, embedded Omega agent > will > > > > send > > > > > a try participate request to alpha server ‘after’ done the try > operation. > > > > > And then in the final phase Alpha will use the participate > information to > > > > > do confirm or cancel operation. > > > > > > > > > > > > > > > > > > > > There is a race condition here: If the omega crashed ‘before’ > sending > > > > > participate request, and left garbage in the system, Alpha server > will do > > > > > nothing about this Omega agent because Alpha server haven’t any > > > > information > > > > > about this participate Omega. > > > > > > > > > > > > > > > > > > > > To avoid this condition, I suggest that Omega agent send > participate > > > > > request ‘before’ do the business operation. Alpha will get enough > > > > > information to cancel this operation even when the Omega crashed. > > > > > > > > > > > > > > > > > > > > What do you guys think about it? > > > > >
