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 Tue, 30 Sep 2008 23:18:16 GMT
> >> > 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.
> >

Let me play devil's advocate here. Yes, one-way MEPs are typically used for
asynchronous messaging. In particular, it makes sense to apply that
constraint when the sending & receiving partners are decoupled from each
other. However, we cannot rule out scenarios where two or more partners
exchange one-way messages in such a way as to form a cycle, thereby
forcing synchronization. For example, let's consider a process P1 that sends
a message to process P2, which sends a message to process P3, which in turn
sends a message back to process P1. The only way to make such a choreography
of one-way messages atomic is to propagate transactions in them.

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

If we assume that one-way MEPs are asynchronous, then I agree that the
sender and receiver must act as if they are unaware of each other. This
constraint makes sense particularly if the underlying transport is JMS,
where the two partners may be separated in time by a broker.

What if we assume that one-way MEPs are asynchronous if and only if the
exchange doesn't propagate the transaction context? If a context is present,
then I think we are obligated to join the partner's transaction.

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