Re: Atomic Scopes

[Karthick Sankarachary <sa...@intalio.com>]

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

Re: Atomic Scopes

[Assaf Arkin <ar...@intalio.com>]

On Tue, Sep 30, 2008 at 4:18 PM, Karthick Sankarachary
<sa...@intalio.com> wrote:
>>
>> >> > 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.

Of course I can, because now we're up one layer in the protocol stack,
the BPEL layer MEP, but the WSDL layer MEPs where transactions happen
are still all asynchronous.


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

You've just described the classical diamond scenario that
transactional systems work hard to avoid.

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

If a context is present, you're going to use it to queue the outgoing
message so it doesn't get transmitted unless the transaction commits,
and in doing do guarantee the ACID properties of the transaction.  But
because it doesn't get transmitted until after (and only if) the
transaction commits, it can't communicate the transaction context.  It
does, however, use the transaction context effectively to guarantee
the ACID properties.

Assaf