I have a little bit confuse with the Participate-End-Event. How will the alpha do when receiving this event ?
As these resources are in the local transaction, I think the alpha does not need to know the detail of these information. Although the omega could crash before registering the participant in the try phase, as Willem mentioned, if we have the @Transactional annotation the transaction manager will rollback them during the recovering after the application start again. In the term of using with no transaction manager support (I assume), I think the omega should provide the similar capability to recovery the resources. The alpha server runs as the coordinator to make a decision to confirm/cancel the global the transaction. So I think it is not very clear to introduce the participate events here to resolve this issue. It's just my two cents. zhaojun <zhaoju...@126.com> 于2019年1月8日周二 下午8:04写道： > 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 > >
