I have got it, it’s necessary to build a pre-write mechanism for these scenario.
> On Jan 8, 2019, at 7:14 PM, Longchun Zhang <longc...@gmail.com> wrote: > > 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? >>>>> >> ------------------ Zhao Jun Apache Sharding-Sphere & ServiceComb
