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? > >
