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
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
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
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
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
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
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
