Atomikos Forum

I'm studying the feasibility of propagating the transaction context in asynchronous invocations. That is, client calls service A synchronously, and A calls service B asynchronously. I want B to execute in the same transaction as A.
The technical name of this is "checked asynchronous transactions": service A returns control to the client and commits later, only after B is done.

So far, the only transaction manager i found that supports this (but i have yet to test it) is JBossTS. For reference here is a link to the discussion i'm having at the JBoss forums about the same topic: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=161221&postdays=0&postorder=asc&start=0

So, is there anything like this in either edition of Atomikos?

Hi,

ExtremeTransactions has 'orphan detection' - which I guess corresponds to what you want.

In other words: a transaction will not commit if there are pending (non-terminated) remote or local children. This mechanism covers both application errors (i.e. not waiting for all results before you commit) and network failures (e.g., lost replies at the application level).

This mechanism also ensures that accidental retries do not lead to double executions in B.

HTH

Thanks for you answer.
But i wonder, is it really equivalent to checked asynchronous transactions?

To quote you "a transaction will not commit if there are pending (non-terminated) remote or local children". But will it wait until those children are no longer active, or will it fail immediately? Checked transactions do the former; the latter can't be used to implement asynchronous transactions.

The last part of your reply seems to suggest that the "orphan detection" mechanism is to be used to ensure correctness in a synchronous execution, even in case of failures.

But that's not what i'm talking about. My use case in the first post is this:
"Client calls service A synchronously, and A calls service B asynchronously. I want B to execute in the same transaction as A."

Under checked transactions, the following deterministic scenario would happen:
1. A is done: the framework tries to commits the transaction
2. The framework detects that the transaction it is trying to commit still has active threads
3. Operation A returns control to its client: the transaction isn’t committed yet
4. The framework waits until the active thread enrolled in the global transaction are done (or a timeout condition is reached)
5. It commits A

I'm asking if this is possible with Atomikos.

Hi,

We never wait for possible outstanding calls (async or sync) to terminate because we explicitly allow for alternatives on failed remote calls. What you describe as checked behavior would be incompatible with this requirement and therefore is impractical as far as we are concerned.

HTH

Allright, thanks for the explanation.

Also, IMHO the checking of whether all replies were received is something that belongs in the application. It is the application that decides on whether to commit, and only the application can know when that time has come... All this is consistent with our interpretation of outstanding calls earlier in this thread.