On Mon, Sep 29, 2008 at 2:33 PM, Karthick Sankarachary <[EMAIL PROTECTED]> wrote: > 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.
Conceptually, if the scope fails it's as if the scope never happened, so the easiest implementation is to mark the transaction for rollback, not store any changes, and evict the instance from memory. > b) The spec doesn't say how atomic scopes should be retried in the case of > faults. By repeating the activity. > 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. If the atomic scope fails, it's as if the scope never happened, in which case we can just retry it again. Eventually we have to give up, and communicate that to the enclosing scope. The enclosing scope can tell what happens because it receives the scopeRollback fault. Due to their semantics, activity failure & recovery and atomic scope are mutually exclusive and not intent to be used together. > 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. Not new, but it doesn't cost us to elaborate on restrictions. > d) Is there a reason why we can't propagate the transaction context in > one-way invokes? Because we're treating two-way as synchronous and one-way as asynchronous (different from request with empty response). Applying these constraints makes it easier to reason about, and pick which MEP to use where. Asynchronous messaging does not propagate atomic transaction from sender & receiver. > The spec contradicts itself by saying that "one-way > receives doesn't use a distributed transaction protocol" (in section 7.2), However, the transaction context can propagate to/from the transport mechanism, e.g. storing the message in a queue, retrieving the message from a queue. We definitely support propagation of the transaction context to/from the transport. In accepting the context on receive, you can make sure the message is consumed only if the transaction commits. > 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, We do want to make them short and that's an easy constraint to apply to the process definition. Discouraging long-running atomic scopes by making them harder to realize is a goal of the spec, not incidental. > 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? 2PC. > 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. Note that JTA is an API, not a protocol. The resource manager enlisted under JTA may use all sort of protocols, we don't have to be aware of or list them. Assaf > > Best Regards, > Karthick Sankarachary >
