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?
