Hi Zheng, Sorry, I forgot that EventAwareInterceptor is in still in PR ( https://github.com/apache/incubator-servicecomb-saga/pull/112)
On Fri, Jan 12, 2018 at 10:53 PM, Zheng Feng <[email protected]> wrote: > Thanks and it works now. > > 2018-01-12 22:28 GMT+08:00 Willem Jiang <[email protected]>: > > > Don't worry, I just add you into the contributor group. Now you can > assign > > the task yourself. > > > > > > Willem Jiang > > > > Blog: http://willemjiang.blogspot.com (English) > > http://jnn.iteye.com (Chinese) > > Twitter: willemjiang > > Weibo: 姜宁willem > > > > On Fri, Jan 12, 2018 at 9:56 PM, Zheng Feng <[email protected]> wrote: > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
