Re: [DISCUSSION] Async support for Saga
OK, I understand and with my prev experiences with the JTA and XA, it looks
similar with the XA.recovery() to get the in-doubt transactions. So the
omega side or the application have to keep the records of the pending
transactions, is it right ?
Willem Jiang 于2019年7月22日周一 下午11:51写道：
> Yes, We can kick off the recovery process or status verify process in
> Alpha if the distribute transaction is in suspend status, but in this
> case we need Alpha talk to customer Application to tell if we need to
> do the recovery again or just do some auditing there. It depends on
> the customer's configuration.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, Jul 22, 2019 at 11:38 PM Zheng Feng wrote:
> >
> > Hi Willem,
> >
> > In the term of providing some further processing extension, you mean that
> > the customer could help the state machine to recovery from the suspension
> > states ?
> >
> > Willem Jiang 于2019年7月22日周一 下午11:28写道：
> >
> > > If we provide the async compensation call, we need to do lots of thing
> > > on Alpha and Omega side. My suggestion we just use provide sync way to
> > > get the feedback of compensation immediately to keep the design
> > > simpler.
> > >
> > > As we are reimplementing the Alpha with state machine, there are some
> > > suspension state which could be caused by the timeout or the missing
> > > event message.
> > > I had a long talk with ZhangLei, we are agree that we could leave the
> > > status check or recovery to the customer by providing some further
> > > processing extension, as there are too many detail things in customer
> > > code to think about.
> > >
> > > Anyway, it's my pleasure to have this kind of discussion with the
> > > team, it's the beauty of Open Source project development, we are
> > > tackling the interesting problem by working together from different
> > > company :)
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Mon, Jul 22, 2019 at 5:14 PM Zheng Feng wrote:
> > > >
> > > > In term of the compensation method, I think I had discussed with
> Willem
> > > > before that it could introduce the @Status annotation for the alpha
> > > server
> > > > to query the compensation status. When the compensation method is
> async
> > > > which means it can not response immediately, it would return the
> > > > COMPENSATING result and the alpha server could query the @Status
> method
> > > to
> > > > check the compensation status, if this method returns COMPENSATE_OK,
> the
> > > > alpha server will mark the local transaction is compensated otherwise
> > > will
> > > > mark it with compensate_failed.
> > > >
> > > > Daniel Qian 于2019年7月21日周日 下午8:37写道：
> > > >
> > > > > I rethink the idea I proposed, yes, provide low level apis is a bad
> > > idea,
> > > > > and I also don't suggest that let user code use omega-xxx-transport
> > > api.
> > > > >
> > > > > I think the essential issues are three:
> > > > >
> > > > >1. How to pass tx context info across threads
> > > > >2. How to asynchronously tell Alpha that Saga is ended or
> aborted,
> > > which
> > > > >means not triggered on @SagaStart method returns.
> > > > >3. How to asynchronously tell Alpha that LocalTx is ended or
> > > aborted,
> > > > >which means not triggered on @Compensable method returns.
> > > > >
> > > > > I think we can keep using @SagaStart @Compensable for the
> > > XXXStartedEvent,
> > > > > and provide a helper to manually end/abort Saga/LocalTx. Thanks
> for PR
> > > #506
> > > > > (SCB-1385) we can use TransactionContext to achieve that. Below is
> a
> > > code
> > > > > sample:
> > > > >
> > > > >
> > > > > @SagaStart(async=true)
> > > > > public void foo() {
> > > > >TransactionContext txContext =
> OmegaContext.getTransactionContext();
> > > > >someAsyncCall()
> > > > > .onSuccess(Callback() {
> > > > > omega.endSaga(txContext);
> > > > > })
> > > > > .onException(Callback() {
> > > > > omega.abortSaga(txContext);
> > > > > })
> > > > > }
> > > > >
> > > > > @Compensable(async=true, compensationMethod="rollbackBar")
> > > > > public void bar() {
> > > > >TransactionContext txContext =
> OmegaContext.getTransactionContext();
> > > > >someAsyncCall()
> > > > > .onSuccess(Callback() {
> > > > > omega.endTx(txContext);
> > > > > })
> > > > > .onException(Callback() {
> > > > > omega.abortTx(txContext);
> > > > > })
> > > > > }
> > > > >
> > > > > The async attribute on @SagaStart and @Compensable prevents
> > > Saga/LocalTx
> > > > > ended when method returns.
> > > > > TransactionContext object can be passed around safely because it's
> > > > > immutable.
> > > > > What I have not considered clearly is that how to deal with
> > > compensation
> > > > > method if it's also async.
> > > > >
> > > > >
> > > > > Willem Jiang 于2019年7月20日周六 下午10:30写道：
> > > > > >
> > > > > > Yeah, I agree we need provide some low level API fo
Re: [DISCUSSION] Async support for Saga
Yes, We can kick off the recovery process or status verify process in
Alpha if the distribute transaction is in suspend status, but in this
case we need Alpha talk to customer Application to tell if we need to
do the recovery again or just do some auditing there. It depends on
the customer's configuration.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Mon, Jul 22, 2019 at 11:38 PM Zheng Feng wrote:
>
> Hi Willem,
>
> In the term of providing some further processing extension, you mean that
> the customer could help the state machine to recovery from the suspension
> states ?
>
> Willem Jiang 于2019年7月22日周一 下午11:28写道：
>
> > If we provide the async compensation call, we need to do lots of thing
> > on Alpha and Omega side. My suggestion we just use provide sync way to
> > get the feedback of compensation immediately to keep the design
> > simpler.
> >
> > As we are reimplementing the Alpha with state machine, there are some
> > suspension state which could be caused by the timeout or the missing
> > event message.
> > I had a long talk with ZhangLei, we are agree that we could leave the
> > status check or recovery to the customer by providing some further
> > processing extension, as there are too many detail things in customer
> > code to think about.
> >
> > Anyway, it's my pleasure to have this kind of discussion with the
> > team, it's the beauty of Open Source project development, we are
> > tackling the interesting problem by working together from different
> > company :)
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Mon, Jul 22, 2019 at 5:14 PM Zheng Feng wrote:
> > >
> > > In term of the compensation method, I think I had discussed with Willem
> > > before that it could introduce the @Status annotation for the alpha
> > server
> > > to query the compensation status. When the compensation method is async
> > > which means it can not response immediately, it would return the
> > > COMPENSATING result and the alpha server could query the @Status method
> > to
> > > check the compensation status, if this method returns COMPENSATE_OK, the
> > > alpha server will mark the local transaction is compensated otherwise
> > will
> > > mark it with compensate_failed.
> > >
> > > Daniel Qian 于2019年7月21日周日 下午8:37写道：
> > >
> > > > I rethink the idea I proposed, yes, provide low level apis is a bad
> > idea,
> > > > and I also don't suggest that let user code use omega-xxx-transport
> > api.
> > > >
> > > > I think the essential issues are three:
> > > >
> > > >1. How to pass tx context info across threads
> > > >2. How to asynchronously tell Alpha that Saga is ended or aborted,
> > which
> > > >means not triggered on @SagaStart method returns.
> > > >3. How to asynchronously tell Alpha that LocalTx is ended or
> > aborted,
> > > >which means not triggered on @Compensable method returns.
> > > >
> > > > I think we can keep using @SagaStart @Compensable for the
> > XXXStartedEvent,
> > > > and provide a helper to manually end/abort Saga/LocalTx. Thanks for PR
> > #506
> > > > (SCB-1385) we can use TransactionContext to achieve that. Below is a
> > code
> > > > sample:
> > > >
> > > >
> > > > @SagaStart(async=true)
> > > > public void foo() {
> > > >TransactionContext txContext = OmegaContext.getTransactionContext();
> > > >someAsyncCall()
> > > > .onSuccess(Callback() {
> > > > omega.endSaga(txContext);
> > > > })
> > > > .onException(Callback() {
> > > > omega.abortSaga(txContext);
> > > > })
> > > > }
> > > >
> > > > @Compensable(async=true, compensationMethod="rollbackBar")
> > > > public void bar() {
> > > >TransactionContext txContext = OmegaContext.getTransactionContext();
> > > >someAsyncCall()
> > > > .onSuccess(Callback() {
> > > > omega.endTx(txContext);
> > > > })
> > > > .onException(Callback() {
> > > > omega.abortTx(txContext);
> > > > })
> > > > }
> > > >
> > > > The async attribute on @SagaStart and @Compensable prevents
> > Saga/LocalTx
> > > > ended when method returns.
> > > > TransactionContext object can be passed around safely because it's
> > > > immutable.
> > > > What I have not considered clearly is that how to deal with
> > compensation
> > > > method if it's also async.
> > > >
> > > >
> > > > Willem Jiang 于2019年7月20日周六 下午10:30写道：
> > > > >
> > > > > Yeah, I agree we need provide some low level API for the user to
> > pass.
> > > > > In the recent change of SCB-1386, I introduce the TransactionContext
> > > > > object which holds the reference of GID and LID, we may add some
> > other
> > > > > transaction context information there too.
> > > > > If the sub transaction is happened in other JVM, we need to pass the
> > > > > TxContext across the JVM with help of omega-xxx-transport.
> > > > >
> > > > > We already have some internal API to send the message from Omega to
> > > > > Alpha, I prefer to use annotation instead of expose low l
Re: [DISCUSSION] Async support for Saga
Hi Willem,
In the term of providing some further processing extension, you mean that
the customer could help the state machine to recovery from the suspension
states ?
Willem Jiang 于2019年7月22日周一 下午11:28写道：
> If we provide the async compensation call, we need to do lots of thing
> on Alpha and Omega side. My suggestion we just use provide sync way to
> get the feedback of compensation immediately to keep the design
> simpler.
>
> As we are reimplementing the Alpha with state machine, there are some
> suspension state which could be caused by the timeout or the missing
> event message.
> I had a long talk with ZhangLei, we are agree that we could leave the
> status check or recovery to the customer by providing some further
> processing extension, as there are too many detail things in customer
> code to think about.
>
> Anyway, it's my pleasure to have this kind of discussion with the
> team, it's the beauty of Open Source project development, we are
> tackling the interesting problem by working together from different
> company :)
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, Jul 22, 2019 at 5:14 PM Zheng Feng wrote:
> >
> > In term of the compensation method, I think I had discussed with Willem
> > before that it could introduce the @Status annotation for the alpha
> server
> > to query the compensation status. When the compensation method is async
> > which means it can not response immediately, it would return the
> > COMPENSATING result and the alpha server could query the @Status method
> to
> > check the compensation status, if this method returns COMPENSATE_OK, the
> > alpha server will mark the local transaction is compensated otherwise
> will
> > mark it with compensate_failed.
> >
> > Daniel Qian 于2019年7月21日周日 下午8:37写道：
> >
> > > I rethink the idea I proposed, yes, provide low level apis is a bad
> idea,
> > > and I also don't suggest that let user code use omega-xxx-transport
> api.
> > >
> > > I think the essential issues are three:
> > >
> > >1. How to pass tx context info across threads
> > >2. How to asynchronously tell Alpha that Saga is ended or aborted,
> which
> > >means not triggered on @SagaStart method returns.
> > >3. How to asynchronously tell Alpha that LocalTx is ended or
> aborted,
> > >which means not triggered on @Compensable method returns.
> > >
> > > I think we can keep using @SagaStart @Compensable for the
> XXXStartedEvent,
> > > and provide a helper to manually end/abort Saga/LocalTx. Thanks for PR
> #506
> > > (SCB-1385) we can use TransactionContext to achieve that. Below is a
> code
> > > sample:
> > >
> > >
> > > @SagaStart(async=true)
> > > public void foo() {
> > >TransactionContext txContext = OmegaContext.getTransactionContext();
> > >someAsyncCall()
> > > .onSuccess(Callback() {
> > > omega.endSaga(txContext);
> > > })
> > > .onException(Callback() {
> > > omega.abortSaga(txContext);
> > > })
> > > }
> > >
> > > @Compensable(async=true, compensationMethod="rollbackBar")
> > > public void bar() {
> > >TransactionContext txContext = OmegaContext.getTransactionContext();
> > >someAsyncCall()
> > > .onSuccess(Callback() {
> > > omega.endTx(txContext);
> > > })
> > > .onException(Callback() {
> > > omega.abortTx(txContext);
> > > })
> > > }
> > >
> > > The async attribute on @SagaStart and @Compensable prevents
> Saga/LocalTx
> > > ended when method returns.
> > > TransactionContext object can be passed around safely because it's
> > > immutable.
> > > What I have not considered clearly is that how to deal with
> compensation
> > > method if it's also async.
> > >
> > >
> > > Willem Jiang 于2019年7月20日周六 下午10:30写道：
> > > >
> > > > Yeah, I agree we need provide some low level API for the user to
> pass.
> > > > In the recent change of SCB-1386, I introduce the TransactionContext
> > > > object which holds the reference of GID and LID, we may add some
> other
> > > > transaction context information there too.
> > > > If the sub transaction is happened in other JVM, we need to pass the
> > > > TxContext across the JVM with help of omega-xxx-transport.
> > > >
> > > > We already have some internal API to send the message from Omega to
> > > > Alpha, I prefer to use annotation instead of expose low level API to
> > > > the user.
> > > >
> > > > Willem Jiang
> > > >
> > > > Twitter: willemjiang
> > > > Weibo: 姜宁willem
> > > >
> > > > On Sat, Jul 20, 2019 at 9:50 PM Daniel Qian
> > > wrote:
> > > > >
> > > > > After look into SCB-163, SCB-1385 and SCB-1386 I have some
> thoughts on
> > > Saga
> > > > > involved in async invocation.
> > > > > Current implementation is basically based on sync invocation,
> there are
> > > > > some assumption:
> > > > >
> > > > >1. When @SagaStart method returns, the Saga finished.
> > > > >2. When @Compensable method returns/throws exception, the Local
> Tx
> > > > >succeeds/failed.
> > > > >
Re: [DISCUSSION] Async support for Saga
If we provide the async compensation call, we need to do lots of thing
on Alpha and Omega side. My suggestion we just use provide sync way to
get the feedback of compensation immediately to keep the design
simpler.
As we are reimplementing the Alpha with state machine, there are some
suspension state which could be caused by the timeout or the missing
event message.
I had a long talk with ZhangLei, we are agree that we could leave the
status check or recovery to the customer by providing some further
processing extension, as there are too many detail things in customer
code to think about.
Anyway, it's my pleasure to have this kind of discussion with the
team, it's the beauty of Open Source project development, we are
tackling the interesting problem by working together from different
company :)
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Mon, Jul 22, 2019 at 5:14 PM Zheng Feng wrote:
>
> In term of the compensation method, I think I had discussed with Willem
> before that it could introduce the @Status annotation for the alpha server
> to query the compensation status. When the compensation method is async
> which means it can not response immediately, it would return the
> COMPENSATING result and the alpha server could query the @Status method to
> check the compensation status, if this method returns COMPENSATE_OK, the
> alpha server will mark the local transaction is compensated otherwise will
> mark it with compensate_failed.
>
> Daniel Qian 于2019年7月21日周日 下午8:37写道：
>
> > I rethink the idea I proposed, yes, provide low level apis is a bad idea,
> > and I also don't suggest that let user code use omega-xxx-transport api.
> >
> > I think the essential issues are three:
> >
> >1. How to pass tx context info across threads
> >2. How to asynchronously tell Alpha that Saga is ended or aborted, which
> >means not triggered on @SagaStart method returns.
> >3. How to asynchronously tell Alpha that LocalTx is ended or aborted,
> >which means not triggered on @Compensable method returns.
> >
> > I think we can keep using @SagaStart @Compensable for the XXXStartedEvent,
> > and provide a helper to manually end/abort Saga/LocalTx. Thanks for PR #506
> > (SCB-1385) we can use TransactionContext to achieve that. Below is a code
> > sample:
> >
> >
> > @SagaStart(async=true)
> > public void foo() {
> >TransactionContext txContext = OmegaContext.getTransactionContext();
> >someAsyncCall()
> > .onSuccess(Callback() {
> > omega.endSaga(txContext);
> > })
> > .onException(Callback() {
> > omega.abortSaga(txContext);
> > })
> > }
> >
> > @Compensable(async=true, compensationMethod="rollbackBar")
> > public void bar() {
> >TransactionContext txContext = OmegaContext.getTransactionContext();
> >someAsyncCall()
> > .onSuccess(Callback() {
> > omega.endTx(txContext);
> > })
> > .onException(Callback() {
> > omega.abortTx(txContext);
> > })
> > }
> >
> > The async attribute on @SagaStart and @Compensable prevents Saga/LocalTx
> > ended when method returns.
> > TransactionContext object can be passed around safely because it's
> > immutable.
> > What I have not considered clearly is that how to deal with compensation
> > method if it's also async.
> >
> >
> > Willem Jiang 于2019年7月20日周六 下午10:30写道：
> > >
> > > Yeah, I agree we need provide some low level API for the user to pass.
> > > In the recent change of SCB-1386, I introduce the TransactionContext
> > > object which holds the reference of GID and LID, we may add some other
> > > transaction context information there too.
> > > If the sub transaction is happened in other JVM, we need to pass the
> > > TxContext across the JVM with help of omega-xxx-transport.
> > >
> > > We already have some internal API to send the message from Omega to
> > > Alpha, I prefer to use annotation instead of expose low level API to
> > > the user.
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Sat, Jul 20, 2019 at 9:50 PM Daniel Qian
> > wrote:
> > > >
> > > > After look into SCB-163, SCB-1385 and SCB-1386 I have some thoughts on
> > Saga
> > > > involved in async invocation.
> > > > Current implementation is basically based on sync invocation, there are
> > > > some assumption:
> > > >
> > > >1. When @SagaStart method returns, the Saga finished.
> > > >2. When @Compensable method returns/throws exception, the Local Tx
> > > >succeeds/failed.
> > > >3. When compensationMethod returns, the Local Tx is compensated.
> > > >
> > > > Even if considering what SCB-100 provided:
> > > >
> > > >1. Add @OmegaContextAware annotation enabling
> > > >java.util.concurrent.Executor inject OmegaConext into threads it
> > > >manages/spawns
> > > >2. Make OmegaContext use InheritableThreadLocal field let child
> > thread
> > > >inherit parent thread's Local Tx info
> > > >
> > > > There are still some limit
Re: [DISCUSSION] Async support for Saga
I think in current implementation of the alpha server, the compensate
invoking is sync and does not pass the transaction context. The other
question is the omega variable should be associated to a thread, I am not
very sure that your proposal could be fine in the multi threads environment.
Daniel Qian 于2019年7月22日周一 下午10:34写道：
> Thanks for the suggestion, Feng.
>
> Did you mean Alpha check if the compensation method finished by
> periodically query @Status method?
>
> If I'm not misunderstanding the code, Alpha doesn't wait for the
> TxCompensatedEvent after
> CompensateCommand sent. That means, the
> CompensateCommand-TxCompensatedEvent
> communication is already async in nature.
>
> So we can take advantage of this async nature and no need to add more event
> types and statuses.
> I think we can add an attribute to indicate compensation method is async on
> @Compensable like this:
>
> @Compensale(compensationMethod="rollbackBar", compensationAsync=true)
> public void bar(arg1, arg2, arg3) {
>// ...
> }
>
> public void rollbackBar(arg1, arg2, arg3, TransactionContextWithParent
> localTx) {
> rollbackAsync()
> .onsuccess(() -> {
>omega.txCompensated(localTx);
> })
> }
>
> Zheng Feng 于2019年7月22日周一 下午5:14写道：
>
> > In term of the compensation method, I think I had discussed with Willem
> > before that it could introduce the @Status annotation for the alpha
> server
> > to query the compensation status. When the compensation method is async
> > which means it can not response immediately, it would return the
> > COMPENSATING result and the alpha server could query the @Status method
> to
> > check the compensation status, if this method returns COMPENSATE_OK, the
> > alpha server will mark the local transaction is compensated otherwise
> will
> > mark it with compensate_failed.
> >
> > Daniel Qian 于2019年7月21日周日 下午8:37写道：
> >
> > > I rethink the idea I proposed, yes, provide low level apis is a bad
> idea,
> > > and I also don't suggest that let user code use omega-xxx-transport
> api.
> > >
> > > I think the essential issues are three:
> > >
> > >1. How to pass tx context info across threads
> > >2. How to asynchronously tell Alpha that Saga is ended or aborted,
> > which
> > >means not triggered on @SagaStart method returns.
> > >3. How to asynchronously tell Alpha that LocalTx is ended or
> aborted,
> > >which means not triggered on @Compensable method returns.
> > >
> > > I think we can keep using @SagaStart @Compensable for the
> > XXXStartedEvent,
> > > and provide a helper to manually end/abort Saga/LocalTx. Thanks for PR
> > #506
> > > (SCB-1385) we can use TransactionContext to achieve that. Below is a
> code
> > > sample:
> > >
> > >
> > > @SagaStart(async=true)
> > > public void foo() {
> > >TransactionContext txContext = OmegaContext.getTransactionContext();
> > >someAsyncCall()
> > > .onSuccess(Callback() {
> > > omega.endSaga(txContext);
> > > })
> > > .onException(Callback() {
> > > omega.abortSaga(txContext);
> > > })
> > > }
> > >
> > > @Compensable(async=true, compensationMethod="rollbackBar")
> > > public void bar() {
> > >TransactionContext txContext = OmegaContext.getTransactionContext();
> > >someAsyncCall()
> > > .onSuccess(Callback() {
> > > omega.endTx(txContext);
> > > })
> > > .onException(Callback() {
> > > omega.abortTx(txContext);
> > > })
> > > }
> > >
> > > The async attribute on @SagaStart and @Compensable prevents
> Saga/LocalTx
> > > ended when method returns.
> > > TransactionContext object can be passed around safely because it's
> > > immutable.
> > > What I have not considered clearly is that how to deal with
> compensation
> > > method if it's also async.
> > >
> > >
> > > Willem Jiang 于2019年7月20日周六 下午10:30写道：
> > > >
> > > > Yeah, I agree we need provide some low level API for the user to
> pass.
> > > > In the recent change of SCB-1386, I introduce the TransactionContext
> > > > object which holds the reference of GID and LID, we may add some
> other
> > > > transaction context information there too.
> > > > If the sub transaction is happened in other JVM, we need to pass the
> > > > TxContext across the JVM with help of omega-xxx-transport.
> > > >
> > > > We already have some internal API to send the message from Omega to
> > > > Alpha, I prefer to use annotation instead of expose low level API to
> > > > the user.
> > > >
> > > > Willem Jiang
> > > >
> > > > Twitter: willemjiang
> > > > Weibo: 姜宁willem
> > > >
> > > > On Sat, Jul 20, 2019 at 9:50 PM Daniel Qian
> > > wrote:
> > > > >
> > > > > After look into SCB-163, SCB-1385 and SCB-1386 I have some thoughts
> > on
> > > Saga
> > > > > involved in async invocation.
> > > > > Current implementation is basically based on sync invocation, there
> > are
> > > > > some assumption:
> > > > >
> > > > >1. When @SagaStart method returns, the Saga finished.
> > > > >2. When @Compensab
Re: [DISCUSSION] Async support for Saga
Thanks for the suggestion, Feng.
Did you mean Alpha check if the compensation method finished by
periodically query @Status method?
If I'm not misunderstanding the code, Alpha doesn't wait for the
TxCompensatedEvent after
CompensateCommand sent. That means, the
CompensateCommand-TxCompensatedEvent
communication is already async in nature.
So we can take advantage of this async nature and no need to add more event
types and statuses.
I think we can add an attribute to indicate compensation method is async on
@Compensable like this:
@Compensale(compensationMethod="rollbackBar", compensationAsync=true)
public void bar(arg1, arg2, arg3) {
// ...
}
public void rollbackBar(arg1, arg2, arg3, TransactionContextWithParent
localTx) {
rollbackAsync()
.onsuccess(() -> {
omega.txCompensated(localTx);
})
}
Zheng Feng 于2019年7月22日周一 下午5:14写道：
> In term of the compensation method, I think I had discussed with Willem
> before that it could introduce the @Status annotation for the alpha server
> to query the compensation status. When the compensation method is async
> which means it can not response immediately, it would return the
> COMPENSATING result and the alpha server could query the @Status method to
> check the compensation status, if this method returns COMPENSATE_OK, the
> alpha server will mark the local transaction is compensated otherwise will
> mark it with compensate_failed.
>
> Daniel Qian 于2019年7月21日周日 下午8:37写道：
>
> > I rethink the idea I proposed, yes, provide low level apis is a bad idea,
> > and I also don't suggest that let user code use omega-xxx-transport api.
> >
> > I think the essential issues are three:
> >
> >1. How to pass tx context info across threads
> >2. How to asynchronously tell Alpha that Saga is ended or aborted,
> which
> >means not triggered on @SagaStart method returns.
> >3. How to asynchronously tell Alpha that LocalTx is ended or aborted,
> >which means not triggered on @Compensable method returns.
> >
> > I think we can keep using @SagaStart @Compensable for the
> XXXStartedEvent,
> > and provide a helper to manually end/abort Saga/LocalTx. Thanks for PR
> #506
> > (SCB-1385) we can use TransactionContext to achieve that. Below is a code
> > sample:
> >
> >
> > @SagaStart(async=true)
> > public void foo() {
> >TransactionContext txContext = OmegaContext.getTransactionContext();
> >someAsyncCall()
> > .onSuccess(Callback() {
> > omega.endSaga(txContext);
> > })
> > .onException(Callback() {
> > omega.abortSaga(txContext);
> > })
> > }
> >
> > @Compensable(async=true, compensationMethod="rollbackBar")
> > public void bar() {
> >TransactionContext txContext = OmegaContext.getTransactionContext();
> >someAsyncCall()
> > .onSuccess(Callback() {
> > omega.endTx(txContext);
> > })
> > .onException(Callback() {
> > omega.abortTx(txContext);
> > })
> > }
> >
> > The async attribute on @SagaStart and @Compensable prevents Saga/LocalTx
> > ended when method returns.
> > TransactionContext object can be passed around safely because it's
> > immutable.
> > What I have not considered clearly is that how to deal with compensation
> > method if it's also async.
> >
> >
> > Willem Jiang 于2019年7月20日周六 下午10:30写道：
> > >
> > > Yeah, I agree we need provide some low level API for the user to pass.
> > > In the recent change of SCB-1386, I introduce the TransactionContext
> > > object which holds the reference of GID and LID, we may add some other
> > > transaction context information there too.
> > > If the sub transaction is happened in other JVM, we need to pass the
> > > TxContext across the JVM with help of omega-xxx-transport.
> > >
> > > We already have some internal API to send the message from Omega to
> > > Alpha, I prefer to use annotation instead of expose low level API to
> > > the user.
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Sat, Jul 20, 2019 at 9:50 PM Daniel Qian
> > wrote:
> > > >
> > > > After look into SCB-163, SCB-1385 and SCB-1386 I have some thoughts
> on
> > Saga
> > > > involved in async invocation.
> > > > Current implementation is basically based on sync invocation, there
> are
> > > > some assumption:
> > > >
> > > >1. When @SagaStart method returns, the Saga finished.
> > > >2. When @Compensable method returns/throws exception, the Local Tx
> > > >succeeds/failed.
> > > >3. When compensationMethod returns, the Local Tx is compensated.
> > > >
> > > > Even if considering what SCB-100 provided:
> > > >
> > > >1. Add @OmegaContextAware annotation enabling
> > > >java.util.concurrent.Executor inject OmegaConext into threads it
> > > >manages/spawns
> > > >2. Make OmegaContext use InheritableThreadLocal field let child
> > thread
> > > >inherit parent thread's Local Tx info
> > > >
> > > > There are still some limitations:
> > > >
> > > >1. @OmegaCont
Re: [PROPOSAL] create e-commerce project as a ServiceComb sample project for user guiding purpose.
I agree with Willem that the example should be simple enough for the first using the ServiceComb. Willem Jiang 于2019年7月22日周一 上午11:17写道： > I think we need to focus on how to use ServiceComb instead of write > another application which only has few audience. > My suggestion is we just break down the requirements and show user > how to do authentication with ServiceComb java-chassis, how to server > the front-end pages with ServiceComb java-chassis, how to interact > with edge service. The example should be simple enough which could be > the start point for user who is first use ServiceComb. > > BTW, ZhengYangYong already write a tutorial[1] about how to use > ServiceComb last year, you may need to consider to build something on > top of that. > > [1]https://github.com/zhengyangyong/scaffold > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Mon, Jul 22, 2019 at 10:57 AM Bin Ma wrote: > > > > It sounds a good idea : ) > > > > Can you briefly show us the design how to use ServiceComb to build > > an e-commerce? thks > > > > > > Best Wishes & Regards > > --- > > Mabin > > > > > > > > 郑志鹏 于2019年7月22日周一 上午10:26写道： > > > > > Thanks for you suggestions. I will make sure the is licensed under > Apache > > > License and the libraries it uses is compatible. And I will make the > > > document as detailed as possible. > > > > > > Liubao (A) 于2019年7月20日周六 下午10:55写道： > > > > > > > Any samples to use ServiceComb is preferred. I have some questions > before > > > > you contribute the code: > > > > > > > >* Make sure the project is licensed under Apache License and the > > > > libraries it uses is compatible. > > > >* Samples are intended to help users how to program. I'd prefer > the > > > > e-commerce project have some documents to describe the project and > the > > > > techniches and best proctics. > > > > > > > > -邮件原件- > > > > 发件人: 郑志鹏 [mailto:aleczhen...@gmail.com] > > > > 发送时间: 2019年7月19日 17:01 > > > > 收件人: dev@servicecomb.apache.org > > > > 主题: [PROPOSAL] create e-commerce project as a ServiceComb sample > project > > > > for user guiding purpose. > > > > > > > > Hi, All > > > > > > > > Recently, I communicated with some ServiceComb new users, they want > an > > > > e-commerce system ServiceComb sample project with real business > > > background. > > > > They think with this demo they can learn ServiceComb’s abilities and > > > > usages *more efficiently*. > > > > > > > > Then I found this project > https://github.com/apache/servicecomb-samples. > > > > So I want to develop an e-commerce system demo and *devote* it to > this > > > > project as this project’s sub-project. > > > > -- > > > > The business background of my planing project: > > > > > > > > Traditionally, a real estate developer in china will show their > nearing > > > > completion buildings to the customers for a couple of days, then > > > determine > > > > an open sale time for all customers to make real deal offline. Those > > > > customers have to get to sale place long before the open sale time > and > > > > queue up,because only in this way they get the chances to pick the > > > > apartment which they like mostly. So recently, more and more real > estate > > > > developers begin to build an online apartments/houses open sale > system. > > > The > > > > e-commerce system help their customer to pick the houses more easily > and > > > > more fairly. This is the system which I plan to build with > ServiceComb. > > > > Why I choose this project as a guiding sample of ServiceComb? > > > > > > > > Real estate developers use this system to make a deal with their > customer > > > > online. So, yes! This is a real e-commerce system with real > commercial > > > > value. But this is also a real simple e-commerce system which has no > > > > payment and shipping module. So Its simplicity is good for the > guiding > > > > purpose. Meanwhile, because these trading subjects of this system are > > > very > > > > expensive，and there will be high QPS when the open sale time just > > > arrives. > > > > So There are high requirements for the system’s scalability, > availability > > > > and robustness.It’s an applicable project to show ServiceComb’s > > > abilities. > > > > Any questions and suggestions? > > > > > > > > -- > > > > Best Wishes & Regards > > > > ——— > > > > Alec Zheng > > > > > > > > > > > > > -- > > > Best Wishes & Regards > > > ——— > > > Alec Zheng > > > >
Re: [DISCUSSION] Async support for Saga
In term of the compensation method, I think I had discussed with Willem
before that it could introduce the @Status annotation for the alpha server
to query the compensation status. When the compensation method is async
which means it can not response immediately, it would return the
COMPENSATING result and the alpha server could query the @Status method to
check the compensation status, if this method returns COMPENSATE_OK, the
alpha server will mark the local transaction is compensated otherwise will
mark it with compensate_failed.
Daniel Qian 于2019年7月21日周日 下午8:37写道：
> I rethink the idea I proposed, yes, provide low level apis is a bad idea,
> and I also don't suggest that let user code use omega-xxx-transport api.
>
> I think the essential issues are three:
>
>1. How to pass tx context info across threads
>2. How to asynchronously tell Alpha that Saga is ended or aborted, which
>means not triggered on @SagaStart method returns.
>3. How to asynchronously tell Alpha that LocalTx is ended or aborted,
>which means not triggered on @Compensable method returns.
>
> I think we can keep using @SagaStart @Compensable for the XXXStartedEvent,
> and provide a helper to manually end/abort Saga/LocalTx. Thanks for PR #506
> (SCB-1385) we can use TransactionContext to achieve that. Below is a code
> sample:
>
>
> @SagaStart(async=true)
> public void foo() {
>TransactionContext txContext = OmegaContext.getTransactionContext();
>someAsyncCall()
> .onSuccess(Callback() {
> omega.endSaga(txContext);
> })
> .onException(Callback() {
> omega.abortSaga(txContext);
> })
> }
>
> @Compensable(async=true, compensationMethod="rollbackBar")
> public void bar() {
>TransactionContext txContext = OmegaContext.getTransactionContext();
>someAsyncCall()
> .onSuccess(Callback() {
> omega.endTx(txContext);
> })
> .onException(Callback() {
> omega.abortTx(txContext);
> })
> }
>
> The async attribute on @SagaStart and @Compensable prevents Saga/LocalTx
> ended when method returns.
> TransactionContext object can be passed around safely because it's
> immutable.
> What I have not considered clearly is that how to deal with compensation
> method if it's also async.
>
>
> Willem Jiang 于2019年7月20日周六 下午10:30写道：
> >
> > Yeah, I agree we need provide some low level API for the user to pass.
> > In the recent change of SCB-1386, I introduce the TransactionContext
> > object which holds the reference of GID and LID, we may add some other
> > transaction context information there too.
> > If the sub transaction is happened in other JVM, we need to pass the
> > TxContext across the JVM with help of omega-xxx-transport.
> >
> > We already have some internal API to send the message from Omega to
> > Alpha, I prefer to use annotation instead of expose low level API to
> > the user.
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Sat, Jul 20, 2019 at 9:50 PM Daniel Qian
> wrote:
> > >
> > > After look into SCB-163, SCB-1385 and SCB-1386 I have some thoughts on
> Saga
> > > involved in async invocation.
> > > Current implementation is basically based on sync invocation, there are
> > > some assumption:
> > >
> > >1. When @SagaStart method returns, the Saga finished.
> > >2. When @Compensable method returns/throws exception, the Local Tx
> > >succeeds/failed.
> > >3. When compensationMethod returns, the Local Tx is compensated.
> > >
> > > Even if considering what SCB-100 provided:
> > >
> > >1. Add @OmegaContextAware annotation enabling
> > >java.util.concurrent.Executor inject OmegaConext into threads it
> > >manages/spawns
> > >2. Make OmegaContext use InheritableThreadLocal field let child
> thread
> > >inherit parent thread's Local Tx info
> > >
> > > There are still some limitations:
> > >
> > >1. @OmegaContextAware is only viable if you use spring framework
> > >2. @OmegaContextAware and OmegaContext's InheritableThreadLocal
> field
> > >assuming that the calling thread or initator thread has Local Tx
> info.
> > >
> > >
> > > What if user code use producer-consumer pattern in which
> > > InheritableThreadLocal can't work?
> > > What if user code use a thread scheduling library which we cannot use
> > > @OmegaContextAware,RxJava and Reactor, for example?
> > > I think we could provide some low-level APIs that user code can manualy
> > > starts/ends Saga and Local Tx, something like below:
> > >
> > > TxContext context = omega.startSaga();
> > > TxContext subTxContext = omega.startTx(TxContext parentTxContext);
> > > omega.endTx(TxContext);
> > > omega.abortTx(TxContext);
> > > omega.abortSaga(TxContext);
> > > omega.endSaga(TxContext);
> > >
> > > TxContext is just a immutable dto like this:
> > >
> > > public class TxContext {
> > > private final String globalTxId;
> > > private final String localTxId;
> > > }
> > >
> > > Above is a just a rough idea. S
