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