RE: [ws-caf] ACTION for optimization of registration

["Green, Alastair J." <Alastair.Green@choreology.com>]

Two or three hasty comments

1. The ability to group enlistments simply requires that a vector be
sent rather than a scalar. There is no inherent need to involve a
"context reply" (as is done in BTP). There is no reason for the
coordinating entity to refuse such vectorized enlistments. 

The purpose of a context reply is distinct: if enrolments/enlistments
arrive in a context reply then the application is "checked": it can
assume that all enrolments required by the service side are those
contained in the context reply. The issue of vectorization and checking
are separate, and both useful. But checking can also be accomplished by
counting and/identification of the participants. 

2. In BTP there is a useful combination: ENROL & PREPARED. This avoids
unnecessary enlistment traffic: if I am prepared then I exist. This
could in turn be vectorized. As it often occurs that only one
participant (a sub-coordinator) will be enlisted, this optimization is
in practice perhaps more important than the one suggested. The semantic
ENROL can of course be implied by the semantic PREPARED (whatever the
actual names chosen).

3. If the facility is intended to be tx protocol independent, then it
should be defined as such, and its implications (if any) for the
coordinator's actions should be separately dealt with in each tx spec.
In the ACID case a failed enlistment does imply a rollback, but this is
not true of non-atomic (non-uniform outcome) protocols. Therefore, I
think there should be a "separation of powers" (correct layering).
Taking this a little further in a different direction: there is no
inherent difference between "direct enlistment failure" and "failure by
proxy". 

4. The last point again raises the need to identify
inferiors/participants.

Alastair 

-----Original Message-----
From: Mark Little [mailto:mark.little@arjuna.com] 
Sent: 07 July 2005 15:34
To: ws-caf
Subject: [ws-caf] ACTION for optimization of registration

ACTION: Mark to write a proposal for the group's consideration to boxcar

registrations, given the room's consensus that it appears to be a 
potentially useful feature.

To summarise the issue 
(http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=55) and the 
text I am proposing: consider the case of an exporting transaction 
domain (e.g., one where the transaction coordinator resides or where it 
was started) making a transactional invocation (one where the context is

associated with an application call) to an importing transaction domain.

The importing domain will do work that must ultimately be controlled by 
the transaction outcome and hence needs to register participants (in 
WS-CF speak that means enlisting participants in the associated activity

group).

Note, this is not specific to WS-ACID and may be applicable to all of 
the transaction models we wish to support.

In some distributed transaction environments, registration of 
participants with a remote coordiantor does not occur immediately within

the importing domain. Rather, the information about the participants 
that should have been enlisted is retained within the importing domain 
until the response to the invocation is sent. In that case, a context is

also propagated back with the response and encoded within this context 
are the EPRs for the participants. The receiver (the original exporting 
domain) is then responsible for enlisting the participants with the 
coordinator.

The advantage of this approach is that it can improve performance, even 
if interposition is used: no cross-domain registration invocations are 
necessary (at least from the importing domain).

The disadvantage is the fact that the registration may fail and in which

case (assuming failure isn't a transient that can be masked by retries) 
the exporting domain must either rollback the transaction or somehow 
communicate with the original importing domain and instruct it to 
rollback its work. In general, it's safer to require that the entire 
transaction is rolled back, or at least marked for ultimate roll back.

If the response fails to be delivered then the sender may retry or 
automatically rollback the work that was done. If the sender retries 
(presumably because it did not receive the response), then the work 
(including registering of participants) will happen again and unless the

importing domain can guarantee idempotent operations (or something akin 
to retained results), it's safer to require rollback and retry.

The important things to remember are that:

a) the importing domain (the one that did the work) has participants 
that have not prepared yet and so, given presumed abort, they can roll 
back autonomously.

b) we don't want split-brain scenario, where the upstream nodes (the 
exporting domain) takes a different course of action to the downstream 
nodes in the transaction tree. Although as I've indicated above there 
are "optimizations" that could be taken in order to negate the necessity

of rolling back the entire transaction in the case of registration 
failure (I'll group failure to deliver the response into this category),

it places more work on the implementation/application and can result in 
non-interoperable/non-portable behaviour. Hence my preference to simply 
err on the safe side and force roll back.

So, here's some proposed text:

"A service that receives a transaction context on an application request

SHOULD enlist participants with the corresponding activity group. The 
transaction service implementation associated with the service MAY 
decide to use the following protocol to optimize remote registration 
invocations: this optimization MAY occur transparently to the service.

Rather than register participants directly, the EPRs of the participants

(and the protocols they should be enlisted with) are retained by the 
service-side transaction service component until the response to the 
original invocation is sent; in which case a context containing these 
EPRs and associated data is propagated back with the response.

If a receiver of a response obtains this context it MUST either be able 
to perform the enlistment itself or, if it does not support this 
optimization, send back a wsacid:CannotOptimizeEnlistment fault code 
message and mark the transaction so that its only outcome is to 
rollback. If enlistment fails then the transaction MUST be rolled back; 
an implementation MAY retry transient registration failures.

If the sender of the response receives an indication that there was a 
non-recoverable failure (e.g., in delivery of the message or 
registration of the participant EPRs) then it MUST rollback the work it 
has performed in the scope of that transaction.

When using this optimization, the service MUST still see a 
wscf:participantAdded message in order to be compliant with WS-CF. 
However, this message SHOULD be generated by the service-side 
transaction component for this optimization to work."

Mark.

-- 
Mark Little
Chief Architect
Arjuna Technologies Ltd
(www.arjuna.com)