Re: Board Report of ServiceComb
Hi, FYI, I just finalized the board report and submitted it to the board: ## Description: - a microservice framework that provides a set of tools and components to make development and deployment of cloud applications easier. ## Issues: - There are no issues requiring board attention at this time. In response to the board query to the previous board report: bd: Are the outcome of your community meetings documented on your dev list? servicecomb: Yeah, we have a wiki[1] page to track the discussion topics, we already sent a mail[2] in the dev-list for the link and started a vote in the mailing list if there is a big decision, such as the vote[3] of the repo rename of servicecomb-saga to servicecomb-pack at the discussion of the meetup. [1]https://cwiki.apache.org/confluence/display/SERVICECOMB/Community+Meeting [2]https://s.apache.org/E8Kz [3]https://s.apache.org/YIFX ## Activity: - ServiceComb PMC did saga-actuator and pack release this month. - We participated in three[1] open source exchange conferences and delivered five times keynote speeches to promote ServiceComb. - Apache ServiceComb won the first prize of China's outstanding open source project organized by China Open Source Cloud Alliance. reference news link[2] - Apache ServiceComb community join Chuanzhiboke Education Technology sub-brand Itheima, Boxuegu and Wisdom Gathering release Apache ServiceComb tutorial. reference news link[3] [1] 1.China Alliance of Industrial Internet Conference, reference link http://www.sohu.com/a/278199186_774700 2.China Cloud Computing Standards and Applications Conference, reference link http://www.zhiding.cn/special/8th_Cloud_Conference#Agenda 3.Chuanzhiboke Carnival and Apache ServiceComb Meetup, reference link https://mp.weixin.qq.com/s/GzWuPHpyZut4H0cuSfTOYA [2]https://blog.csdn.net/ServiceComb/article/details/84989759 [3]http://servicecomb.apache.org/docs/chuanzhiboke-servicecomb-tutoria-release/ ## Health report: - The mails and commits activity are as good as usual. ## PMC changes: - Currently 16 PMC members. - No new PMC members added in the last 3 months ## Committer base changes: - Currently 18 committers. ## Releases: - ServiceComb Pack 0.3.0 was released on Wed Jan 02 2019 - ServiceComb Saga Actuator 0.3.0 was released on Tue Dec 18 2018 ## Mailing list activity: This month there are 1225 emails sent to servicecomb.apache.org by 38 people, divided into 796 topics Top 5 member: GitBox: 541 email(s) ASF GitHub Bot (JIRA): 208 email(s) ningji...@apache.org: 118 email(s) Willem Jiang (JIRA): 105 email(s) liu...@apache.org: 45 email(s) - dev@servicecomb.apache.org: - This month there are 56 emails sent by 18 people, divided into 12 topics. - 137 subscribers (up 17 in the last 3 months): - 347 emails sent to list (634 in previous quarter) - iss...@servicecomb.apache.org: - 8 subscribers (up 0 in the last 3 months): - 1674 emails sent to list (2708 in previous quarter) ## JIRA activity: - 152 JIRA tickets created in the last 3 months - 153 JIRA tickets closed/resolved in the last 3 months Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Tue, Jan 8, 2019 at 11:06 AM Bin Ma wrote: > > OK, updated and added the reference link as below, > > In community operations and promotional activities in December, > 1. We participated in three[1] open source exchange conferences and > delivered five times keynote speeches to promote ServiceComb. > 2. Apache ServiceComb won the first prize of China's outstanding open > source project organized by China Open Source Cloud Alliance. reference > news link[2] > 3. Apache ServiceComb community joint Chuanzhiboke Education Technology > sub-brand Itheima, Boxuegu and Wisdom Gathering release Apache ServiceComb > tutorial. reference news link[3] > > [1] > 1.China Alliance of Industrial Internet Conference, reference link > http://www.sohu.com/a/278199186_774700 > 2.China Cloud Computing Standards and Applications Conference, reference > link http://www.zhiding.cn/special/8th_Cloud_Conference#Agenda > 3.Chuanzhiboke Carnival and Apache ServiceComb Meetup, reference link > https://mp.weixin.qq.com/s/GzWuPHpyZut4H0cuSfTOYA > [2]https://blog.csdn.net/ServiceComb/article/details/84989759 > [3]https://www.toutiao.com/i6639922959018361348/ > > > > Best Wishes & Regards > --- > Mabin > > > > Willem Jiang 于2019年1月8日周二 上午10:11写道： > > > Hi Mabin, > > > > It could be more useful if we could include the news link or the reports. > > > > Willem Jiang > > > > Twitter: willemjiang > > Weibo: 姜宁willem > > > > On Tue, Jan 8, 2019 at 10:03 AM Bin Ma wrote: > > > > > > Please help to review whether the following content needs to be presented > > > in the report,thks > > > > > > In community operations and promotional activities in December, > > > 1. We participated in three[1] open source exchange conferences and > > > delivered five times keynote speeches to promote
Re: Garbage may be left when the omega crashed before sending participate request
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 于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 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 > 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 > >> 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 > >> 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 > >> 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 > >> 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 >
Re: Garbage may be left when the omega crashed before sending participate request
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 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 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 >> 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 >> 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 >> 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 >> 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
Re: Garbage may be left when the omega crashed before sending participate request
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 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 > 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 > 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 > 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 > 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? > > > > >
Re: Garbage may be left when the omega crashed before sending participate request
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 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 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 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 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? > > >
Re: Garbage may be left when the omega crashed before sending participate request
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 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 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 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? > >
Re: Garbage may be left when the omega crashed before sending participate request
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 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 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? >
Re: Garbage may be left when the omega crashed before sending participate request
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 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?
Re: Garbage may be left when the omega crashed before sending participate request
Hi, Zhang Now Alpha side have a timeout mechanism to avoid this happen. If a global transaction have exceeded timeout setting, alpha will send compensation command to terminate this transaction. We also consider about writing event log in omega side to reduce complexity of alpha side. -- Zhao Jun Apache Sharding-Sphere & ServiceComb > On Jan 8, 2019, at 3:58 PM, Longchun Zhang 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?
