ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karthick Sankarachary" <sankarach...@intalio.com>
Subject Atomic Scopes
Date Mon, 29 Sep 2008 21:33:23 GMT
Just a few quick observations on the atomic
scopes<http://ode.apache.org/atomic-scopes-extension-for-bpel.html>
 spec:

a)  The state of a scope consists of not just its variables but also its
correlation sets. So, just like assigns are collectively atomic, correlation
sets must be collectively atomic too. The easiest way to implement this
would be to take a checkpoint of all variable and correlation state when the
atomic scope begins, so that if anything should go wrong, we simply rollback
to that checkpoint.

b) The spec doesn't say how atomic scopes should be retried in the case of
faults. Apparently, there already exists a fault &
recovery<http://ode.apache.org/activity-failure-and-recovery.html>
spec
that addresses retries. To use that feature, I suggest replacing the
atomic:scopeRollback fault with the ext:activityFailure fault. In
particular, if a two-way invoke inside an atomic scope fails due to a
distributed rollback or some other invoke-specific fault, then it should
throw an ext:activityFailure, which is caught and retried in the
<ext:failureHandling> element defined for the atomic scope. In addition, we
should extend the failure mechanism to the other message activities, such as
receive and reply, so that they too are able to trigger the retry mechanism
in an atomic scope.

c) In section 4, the spec says that the receive/reply must not cross the
boundary of the atomic scope. However, this is not really a new requirement,
since the standard already says that a bpel:missingReply be thrown in such
cases.

d) Is there a reason why we can't propagate the transaction context in
one-way invokes? The spec contradicts itself by saying that "one-way
receives doesn't use a distributed transaction protocol" (in section 7.2),
and stating that "an atomic scope that begins by receiving a message using a
distributed transaction protocol must enroll in the transaction and
participate in determining the outcome of that transaction" (in section
7.1). Personally, I think that both one-way receives and one-way invokes
should propagate the transaction context, if at all possible. In the case of
one-way invokes, we should try to send the message right away along with the
context, and perform a 2-phase commit with the invoked service when the
scope ends. If the transaction context cannot be propagated, then we should
wait for the atomic scope to end before sending the message. Similarly, in
the case of one-way receives, if the incoming message contains a transaction
context, then we consume the message (from our internal queue) right away.
If no context was sent, then we consume the message only if the atomic scope
completes, because the partner will not re-send it.

e) In addition to intermediate one-way invokes, we should allow intermediate
one-way receives too. I understand the need to keep atomic scopes
short-running, but there may be cases where you may want an intermediate
receive to be part of the atomic transaction. If the message sent to a
one-way receive has a transaction context, then the atomic scope joins with
the partner's transaction. When the atomic scope ends, we first prepare all
global transactions, and commit all transactions only if all the prepares
were successful. To ensure that such atomic scopes don't run forever, the
user should be able to optionally set a transaction timeout.

f) What kinds of distributed transaction protocols do we want to support?
There's a Axis2-based implementation of WS-AtomicTransaction called Kandula,
but that's only going to work for the Axis2 IL. What about the SCA and JBI
ILs? Alternatively, do we want to use JTA in the case of message activities
that are backed by a co-located resource, such as a database? The advantage
of JTA is that it is not IL-specific, but on the flip side, it is not a
generic solution.

Best Regards,
Karthick Sankarachary

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message