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