Re: [DISCUSSION] Async support for Saga
You don't need to remove the TxComensatedEvent sending code.
I think you just need to throw a runtime exception in the onReceive
method to see if the Alpha can get the error.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Wed, Jul 24, 2019 at 10:33 PM Daniel Qian wrote:
>
> Hi Willem. I did some experiment on CompensationMessageHandler.
>
> In first case, I send a delayed TxCompensatedEvent to simulate async
> TxCompensated notification:
>
> @Override
> public void onReceive(final String globalTxId, final String localTxId,
> final String parentTxId, final String compensationMethod,
> Object... payloads) {
> context.apply(globalTxId, localTxId, compensationMethod, payloads);
> new Thread(new Runnable() {
> @Override
> public void run() {
> try {
> Thread.sleep(1L);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> sender.send(new TxCompensatedEvent(globalTxId, localTxId,
> parentTxId, compensationMethod));
> }
> }).start();
> }
>
> I watched command table and found that compensation command status
> PENDING -> DONE transition.
> I also watched txevent table found SagaEnded correctly:
>
> In second case, I just remove TxCompensatedEvent sending code:
>
> @Override
> public void onReceive(final String globalTxId, final String localTxId,
> final String parentTxId, final String compensationMethod,
> Object... payloads) {
> context.apply(globalTxId, localTxId, compensationMethod, payloads);
> }
>
> In command table compensation command remains PENDING and in txevent
> table no SagaEndedEvent happens.
>
> Zheng Feng 于2019年7月24日周三 下午4:07写道：
> >
> > So the grpc could support the async invoking ?
> >
> > Willem Jiang 于2019年7月24日周三 下午2:31写道：
> >
> > > Hi Daniel,
> > >
> > > If you take a look at the Omega side, the CompensationMessageHandler
> > > is called in onNext() method of GrpcCompensateStreamObserver.
> > > If there is something wrong with CompensationMessageHandler
> > > onReceive() method, the Stream could be broken and Alpha can now about
> > > it immediately. (You can write a simple test case to verify it).
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Wed, Jul 24, 2019 at 12:27 PM Daniel Qian
> > > wrote:
> > > >
> > > > Thanks for sharing your thoughts, Willem. But I didn't really get your
> > > > point.
> > > >
> > > > I read the code and found that compensation action works like this:
> > > >
> > > > 1. Alpha GrpcOmegaCallback send GrpcCompensateCommand to Omega
> > > > 2. Omega CompensationMessageHandler handle the command, execute
> > > > compensation logic and send TxCompensatedEvent to Alpha
> > > >
> > > > In this progress, Alpha doesn't wait for compensation success message
> > > > after sending compensation command, it just returns. So the progress is
> > > > already async.
> > > >
> > > > If what I said above is correct, please read the following, if not,
> > > please
> > > > correct me.
> > > >
> > > > As to the current implementation, it's possible that compensation
> > > > command
> > > > is sent but no compensation success message received. I think what you
> > > > said is Alpha should have a mechanism to handle compensation timeout,
> > > > retry or just log it. But I think this an improvement should be done on
> > > the
> > > > Alpha side. Am I right?
> > > >
> > > > In my opinion, to support async compensation, the only thing need to do
> > > is
> > > > providing a way to let user code send TxCompensatedEvent. Sure I don't
> > > mean
> > > > that we should expose the underly communication,
> > > > GrpcSagaClientMessageSender
> > > > for example, to user code. Providing a encapsulated interface will be
> > > > better,
> > > > just like what I mentioned before.
> > > >
> > > > Zheng Feng 于2019年7月23日周二 下午2:10写道：
> > > > >
> > > > > 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
> > > > > > >
Re: [DISCUSSION] Async support for Saga
Hi Willem. I did some experiment on CompensationMessageHandler.
In first case, I send a delayed TxCompensatedEvent to simulate async
TxCompensated notification:
@Override
public void onReceive(final String globalTxId, final String localTxId,
final String parentTxId, final String compensationMethod,
Object... payloads) {
context.apply(globalTxId, localTxId, compensationMethod, payloads);
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(1L);
} catch (InterruptedException e) {
e.printStackTrace();
}
sender.send(new TxCompensatedEvent(globalTxId, localTxId,
parentTxId, compensationMethod));
}
}).start();
}
I watched command table and found that compensation command status
PENDING -> DONE transition.
I also watched txevent table found SagaEnded correctly:
In second case, I just remove TxCompensatedEvent sending code:
@Override
public void onReceive(final String globalTxId, final String localTxId,
final String parentTxId, final String compensationMethod,
Object... payloads) {
context.apply(globalTxId, localTxId, compensationMethod, payloads);
}
In command table compensation command remains PENDING and in txevent
table no SagaEndedEvent happens.
Zheng Feng 于2019年7月24日周三 下午4:07写道：
>
> So the grpc could support the async invoking ?
>
> Willem Jiang 于2019年7月24日周三 下午2:31写道：
>
> > Hi Daniel,
> >
> > If you take a look at the Omega side, the CompensationMessageHandler
> > is called in onNext() method of GrpcCompensateStreamObserver.
> > If there is something wrong with CompensationMessageHandler
> > onReceive() method, the Stream could be broken and Alpha can now about
> > it immediately. (You can write a simple test case to verify it).
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Wed, Jul 24, 2019 at 12:27 PM Daniel Qian
> > wrote:
> > >
> > > Thanks for sharing your thoughts, Willem. But I didn't really get your
> > > point.
> > >
> > > I read the code and found that compensation action works like this:
> > >
> > > 1. Alpha GrpcOmegaCallback send GrpcCompensateCommand to Omega
> > > 2. Omega CompensationMessageHandler handle the command, execute
> > > compensation logic and send TxCompensatedEvent to Alpha
> > >
> > > In this progress, Alpha doesn't wait for compensation success message
> > > after sending compensation command, it just returns. So the progress is
> > > already async.
> > >
> > > If what I said above is correct, please read the following, if not,
> > please
> > > correct me.
> > >
> > > As to the current implementation, it's possible that compensation command
> > > is sent but no compensation success message received. I think what you
> > > said is Alpha should have a mechanism to handle compensation timeout,
> > > retry or just log it. But I think this an improvement should be done on
> > the
> > > Alpha side. Am I right?
> > >
> > > In my opinion, to support async compensation, the only thing need to do
> > is
> > > providing a way to let user code send TxCompensatedEvent. Sure I don't
> > mean
> > > that we should expose the underly communication,
> > > GrpcSagaClientMessageSender
> > > for example, to user code. Providing a encapsulated interface will be
> > > better,
> > > just like what I mentioned before.
> > >
> > > Zheng Feng 于2019年7月23日周二 下午2:10写道：
> > > >
> > > > 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
> > > > > >
Re: [DISCUSSION] Async support for Saga
So the grpc could support the async invoking ? Willem Jiang 于2019年7月24日周三 下午2:31写道： > Hi Daniel, > > If you take a look at the Omega side, the CompensationMessageHandler > is called in onNext() method of GrpcCompensateStreamObserver. > If there is something wrong with CompensationMessageHandler > onReceive() method, the Stream could be broken and Alpha can now about > it immediately. (You can write a simple test case to verify it). > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Wed, Jul 24, 2019 at 12:27 PM Daniel Qian > wrote: > > > > Thanks for sharing your thoughts, Willem. But I didn't really get your > > point. > > > > I read the code and found that compensation action works like this: > > > > 1. Alpha GrpcOmegaCallback send GrpcCompensateCommand to Omega > > 2. Omega CompensationMessageHandler handle the command, execute > > compensation logic and send TxCompensatedEvent to Alpha > > > > In this progress, Alpha doesn't wait for compensation success message > > after sending compensation command, it just returns. So the progress is > > already async. > > > > If what I said above is correct, please read the following, if not, > please > > correct me. > > > > As to the current implementation, it's possible that compensation command > > is sent but no compensation success message received. I think what you > > said is Alpha should have a mechanism to handle compensation timeout, > > retry or just log it. But I think this an improvement should be done on > the > > Alpha side. Am I right? > > > > In my opinion, to support async compensation, the only thing need to do > is > > providing a way to let user code send TxCompensatedEvent. Sure I don't > mean > > that we should expose the underly communication, > > GrpcSagaClientMessageSender > > for example, to user code. Providing a encapsulated interface will be > > better, > > just like what I mentioned before. > > > > Zheng Feng 于2019年7月23日周二 下午2:10写道： > > > > > > 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
Re: [DISCUSSION] Async support for Saga
Hi Daniel, If you take a look at the Omega side, the CompensationMessageHandler is called in onNext() method of GrpcCompensateStreamObserver. If there is something wrong with CompensationMessageHandler onReceive() method, the Stream could be broken and Alpha can now about it immediately. (You can write a simple test case to verify it). Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Wed, Jul 24, 2019 at 12:27 PM Daniel Qian wrote: > > Thanks for sharing your thoughts, Willem. But I didn't really get your > point. > > I read the code and found that compensation action works like this: > > 1. Alpha GrpcOmegaCallback send GrpcCompensateCommand to Omega > 2. Omega CompensationMessageHandler handle the command, execute > compensation logic and send TxCompensatedEvent to Alpha > > In this progress, Alpha doesn't wait for compensation success message > after sending compensation command, it just returns. So the progress is > already async. > > If what I said above is correct, please read the following, if not, please > correct me. > > As to the current implementation, it's possible that compensation command > is sent but no compensation success message received. I think what you > said is Alpha should have a mechanism to handle compensation timeout, > retry or just log it. But I think this an improvement should be done on the > Alpha side. Am I right? > > In my opinion, to support async compensation, the only thing need to do is > providing a way to let user code send TxCompensatedEvent. Sure I don't mean > that we should expose the underly communication, > GrpcSagaClientMessageSender > for example, to user code. Providing a encapsulated interface will be > better, > just like what I mentioned before. > > Zheng Feng 于2019年7月23日周二 下午2:10写道： > > > > 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 > > > > >
