yeah, I raised https://issues.apache.org/jira/browse/SCB-228 for the issue of TxEvent type and feel free to assign to me. I think I have no access to assign myself as I am not the member of the servicecomb
2018-01-12 17:39 GMT+08:00 Willem Jiang <[email protected]>: > Hi FengZheng， > > It's good to see you here and we are looking forward your valuable inputs > and contribution :) > > > Willem Jiang > > Blog: http://willemjiang.blogspot.com (English) > http://jnn.iteye.com (Chinese) > Twitter: willemjiang > Weibo: 姜宁willem > > On Fri, Jan 12, 2018 at 3:38 PM, Zheng Feng <[email protected]> wrote: > > > comment inline, > > > > 2018-01-12 10:17 GMT+08:00 Sean Yin <[email protected]>: > > > > > Hi Zheng, > > > > > > Thank you for taking your time to go through our Pack architecture of > > > ServiceComb Saga. > > > > > > 1. The Omega acts like a 'Saga Participant' and the Alpha looks like a > > > > 'Saga Coordinator'. > > > > 2. They communicate each other with the underlying gRPC connections. > > > > > > > > > You are right about the roles of Omega and Alpha in this architecture. > > And > > > the suggestions you provided are very valuable to us. > > > > > > 3. The TxEvent is defined as the sequences of the record, such like > > > > SagaStartedEvent, SagaEndedEvent, TxStartedEvent, TxEndedEvent, > > > > TxAbortedEvent, TxCompensatedEvent. And currently the event type is > > > relied > > > > by the TxEvent className. I think it would be better to use the enum > > type > > > > since the class name could be changed with the issue of > compatibility. > > > > > > > > > We are in short of developers and cut some corners in our > implementation, > > > such as using TxEvent class names as event type. :) > > > > > OK, I will raise a SCB jira for this if you agree. > > > > > > > > 4. The annotation SagaStart is used to indicate the boundary edge of > the > > > > Saga Transaction. I assume that we can use like the following > > > > @SagaStart > > > > public Response svc( ) { > > > > restTemplate() -> invoke (serviceA); > > > > retsTemplate() -> invoke (serviceB); > > > > } > > > > > > > > > Yes, we have integration tests to illustrate this idea in pack-tests > > > module. > > > > > > So I suggest that we use the @Saga or @SagaContext to replace the > > > > @SagaStart to make it clear. Also in the processor of this > annotation, > > > the > > > > SagaStartedEvent and SagaEndedEvent are sent. > > > > > > > > > Proper naming is hard and we can definitely give it more thoughts. > > Indeed, > > > we have code to send SagaStartedEvent and SagaEndedEvent around > > @SagaStart > > > in success scenario. > > > In failure cases, we try to achieve that Alpha writes SagaEndedEvent by > > > itself, since compensations are done asynchronously. > > > > > > 5. After going through the omega codes, I think it could be possible to > > > > introduce a OmegaClient interface to handle all of the events related > > > with > > > > the Saga. some pseudo code looks like > > > > public interface OmegaClient { > > > > void saga_start( ); > > > > void saga_close( ); > > > > void saga_cancel( ); > > > > void saga_tx_start( ); > > > > void saga_tx_end( ); > > > > void saga_tx_failed( ); > > > > void saga_compensate( ); > > > > } > > > > So we can get the GrpcOmegaClient to implement it with the gRPC > > > > connection. This could be helpful if we have the other underlying > > > > connection in the future. > > > > > > > > > We do have a communication interface (MessageSender) for potential > > > extension in the future. And another interface (EventAwareInterceptor) > > for > > > composing these saga events. > > > Like you said, we probably should have given methods in > > > EventAwareInterceptor more meaningful names. > > > > > Can you point me the link for the EventAwareInterceptor ? I can not find > it > > in the incubator-servicecomb-saga. > > > > > > > > 6. I have not find any annotation with the participant. So it could be > > > > possible to introduce the @Participant just like > > > > public class ServiceA { > > > > @Participant > > > > public Response work( ); > > > > @Compensate > > > > public void undo( ); > > > > } > > > > > > > > > The annotation for partcipants is @Compensable. > > > > > > and it could be useful to add the type SUPPORT, NOT_SUPPORT, > > MANDATORY, > > > > > > > > > I did not quite understand what you mean. Could you please elaborate a > > bit > > > more? > > > > > The idea is from the traditional transaction of EJB, you can find > > https://docs.oracle.com/javaee/6/tutorial/doc/bncij.html > > > > > > > > You have been working on data consistency problems for quite a while > and > > > must have many useful insights. > > > We are very lucky if you join us on this project! > > > > > > Thank you! > > > > > > Best Regards, > > > Sean > > > > > > On Fri, Jan 12, 2018 at 9:28 AM, Zheng Feng <[email protected]> wrote: > > > > > > > Hi all, > > > > > > > > I've tried to understand about the new architecture PACK of the > > > > servicecomb-saga. > > > > > > > > 1. The Omega acts like a 'Saga Participant' and the Alpha looks like > a > > > > 'Saga Coordinator'. > > > > 2. They communicate each other with the underlying gRPC connections. > > > > 3. The TxEvent is defined as the sequences of the record, such like > > > > SagaStartedEvent, SagaEndedEvent, TxStartedEvent, TxEndedEvent, > > > > TxAbortedEvent, TxCompensatedEvent. And currently the event type is > > > relied > > > > by the TxEvent className. I think it would be better to use the enum > > type > > > > since the class name could be changed with the issue of > compatibility. > > > > 4. The annotation SagaStart is used to indicate the boundary edge of > > the > > > > Saga Transaction. I assume that we can use like the following > > > > @SagaStart > > > > public Response svc( ) { > > > > restTemplate() -> invoke (serviceA); > > > > retsTemplate() -> invoke (serviceB); > > > > } > > > > So I suggest that we use the @Saga or @SagaContext to replace the > > > > @SagaStart to make it clear. Also in the processor of this > annotation, > > > the > > > > SagaStartedEvent and SagaEndedEvent are sent. > > > > > > > > 5. After going through the omega codes, I think it could be possible > to > > > > introduce a OmegaClient interface to handle all of the events related > > > with > > > > the Saga. some pseudo code looks like > > > > public interface OmegaClient { > > > > void saga_start( ); > > > > void saga_close( ); > > > > void saga_cancel( ); > > > > void saga_tx_start( ); > > > > void saga_tx_end( ); > > > > void saga_tx_failed( ); > > > > void saga_compensate( ); > > > > } > > > > So we can get the GrpcOmegaClient to implement it with the gRPC > > > > connection. This could be helpful if we have the other underlying > > > > connection in the future. > > > > > > > > 6. I have not find any annotation with the participant. So it could > be > > > > possible to introduce the @Participant just like > > > > > > > > public class ServiceA { > > > > @Participant > > > > public Response work( ); > > > > > > > > @Compensate > > > > public void undo( ); > > > > } > > > > and it could be useful to add the type SUPPORT, NOT_SUPPORT, > > > MANDATORY, > > > > ... > > > > > > > > Anyway, I will be happy to involved in the servicecomb saga and > welcome > > > for > > > > any input. > > > > > > > > Thanks, > > > > Zheng > > > > > > > > > >
