ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: Atomic Scopes
Date Mon, 29 Sep 2008 23:09:57 GMT
On Mon, Sep 29, 2008 at 3:46 PM, Karthick Sankarachary
<sankarachary@intalio.com> wrote:
>> > b) The spec doesn't say how atomic scopes should be retried in the case
>> of
>> > faults.
>> By repeating the activity.
> Does that mean that we have to redefine the <ext:retryFor> and
> <ext:retryDelay> options for the atomic scope activity?

Only if people have problem with these two being specified globally
and need to exert more control.

>> Due to their semantics, activity failure & recovery and atomic scope
>> are mutually exclusive and not intent to be used together.
> The only reason we would want to retry an atomic scope is because one of
> child activities fails due to a transient problem. Isn't that the same
> problem that the activity failure & recovery spec tries to address?

It's precisely that they intersect in some way, but are totally
different constructs designed primarily to support different use
cases, that makes them mutually exclusive.  They are both mechanisms
for error handling and recovery, and keeping them separate makes it
easier to reason about and properly use each one.

>> > 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.
> Does WS-AtomicTransaction disallow atomic transactions for one-way
> exchanges?

Do we care?  Constraints are a really good thing, and this is one
place that makes life really easy.  There's a lot to gain from
applying constraints and pattern semantics on the operation, ahead of
when the bindings are known.  This does not preclude you from doing
request/empty-response, but makes a clear separation between blocking
and non.

>> > 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.
> What happens the sender of the message consumed by the receive rollbacks?

In asynchronous messaging, the sender transaction must complete before
the message becomes visible to the receiver; if the sender transaction
rolled back, there's no message for the receiver to process.

If the sender and receiver were somehow tied to the same transaction,
they're now synchronized, we're talking about synchronous not
asynchronous messaging.  It's the one point of distinction most people
get wrong initially, and one reason why life is easier when you can
clearly identify synchronous and asynchronous patterns.

>  Don't we want to be able to rollback the process that received that
> message, even though it is prepared to commit?
>> > 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.
> In my opinion, the transaction timeout mechanism gives us the best of both
> worlds. It gives you a way to write short-running processes with
> intermediate receives.

Again, the point of the spec is to pick the best practice and
encourage it, while discouraging other behaviors or leaving them to
more courageous implementations (say, Java code).


> Best Regards,
> Karthick Sankarachary

View raw message