ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karthick Sankarachary" <sankarach...@intalio.com>
Subject Re: Atomic Scopes
Date Mon, 29 Sep 2008 22:46:23 GMT
> > 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?

> 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?

> > 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

> > 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?
 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.

Best Regards,
Karthick Sankarachary

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