In sync invocation scenario, we can tell tx is finished once the
execution finished, and tx context
can be obtained from thread local implicitly, that's just how we do in
current implementation.
In async invocation scenario, there are various async patterns,
various libs, various tools to do
For the first scenario, we can address it with countdown (and timeout)
check , as each async invocation only have one local-transaction (or
sub-transaction).
For the second scenario, as the topic publisher and topic subscribers
are decoupled, it's impossible for Alpha to find out if all the
Hi, Team
For asynchronous, I think we need to distinguish between two scenario
1. After the asynchronous method is executed, the sub-transaction execution
ends, for example: using internal threads to execute.
For this scenario, we allow sub-transactions to be in parallel, but we must
wait for
TxAsyncStarted is just let Alpha know there is an async transaction
invocation, as the local transaction is not started yet, we can only
connect the TxAsyncStarted event LocalTransactionID with TxStarted
event ParentTransactionID.
Once Alpha receives the TxAsyncStarted event, it should wait for
Hi Willem,
I am not very clear about the TxAsyncStart event ? what's the difference
between the TxAyncStart and TxStarted Event. How does the alpha process the
async events ?
Thanks,
Zheng Feng
Willem Jiang 于2019年7月30日周二 上午8:41写道：
> According to the feedback for PR, I think we need to rethink
To send out the TxAasyncStart, we have to intercept the async
invocation to send out the event. It's could be a challenge for us to
list all the async invocation.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Tue, Jul 30, 2019 at 8:40 AM Willem Jiang wrote:
>
> According to the feedback
Export the low level API could introduce some error if the user
doesn't use the API rightly.
My suggestion is we just
BTW, I submit a PR[1] to address this issue in a simple way (But we
still need to tell user what's the right way to configure the
annotation attribute).
Hi Zhang Lei,
What I'm trying to say is to provide a way for user to send
TxEndedEvent, TxAbortedEvent, TxCompensatedEvent, SagaEndedEvent ...
explicitly on Omega side.
Because current implementation doesn't support following situation(async):
@Compensable(compensationMethod="rollbackFoo")
Hi, Daniel Qian
Are you talking about the asynchronous problem with the @SagaStart and
@Compensable methods on the Omega side? I think this is a typical long
transaction scene.
Alpha based on Actor model has implemented asynchronous processing of Omega and
Alpha, The event sent to Alpha needs
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.
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
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
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
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
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
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
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
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
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
23 matches
Mail list logo
