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

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

Greg,

Amalgamating responses to your point and Mark's earlier ones.

I think the idea of context backflow is the wrong way to think of (the
first part of) this discussion. 

It isn't a context or a context reply, it's a vector of enlistment
messages. 

(And to repeat, because it may have been buried: I see no reason why an
implementation should be free to refuse to attempt to process such a
vector. 
If it is accepted that there is no need for a message tns:iDontDoThis in
response to a vectorized attempt, then there is no need to argue about
whether tns = wsacid or wstxm, which is the acid-specific reference I
objected to in the proposed text.)

You can obviously handle that vectorization in WS-CF.

The moral equivalent of "prepared" (carrying the implicit semantic of
WS-CF enlistment, participant-addition or whatever) is not able to be
represented in WS-CF. As I said, this is a more relevant optimization in
actuality. This means that a statement must be made in WS-TXM about the
WS-CF implications of a WS-TXM message. 

The idea of using a context reply (a la BTP) as a punctuation mark, to
indicate to the app: "all enlistments done", "checked" is a useful but
separate idea. It is a concept that belongs in WS-CF, I agree. I imagine
in WS-CAF terms this would be an augmented version of the original
context?

Its interpretation with respect to transactional behaviour is not a
WS-CF concept. 

Then there is the issue: what about the uber-optimization of enclosing
or concatenating the application protocol message "checked" with the
vectorized protocol messages wscf:enlist and wstxm:prepared (I know
they're not really called that, just for expository purposes)?

Alastair


Alastair J. Green
CEO and CTO
Choreology Ltd
68 Lombard Street
London EC3V 9LJ
www.choreology.com

+44 870 739 0050
+44 870 739 0051 (fax)
+44 795 841 2107 (mobile)


-----Original Message-----
From: Greg Pavlik [mailto:greg.pavlik@oracle.com] 
Sent: 12 July 2005 16:29
To: Green, Alastair J.
Cc: Mark Little; ws-caf
Subject: Re: [ws-caf] ACTION for optimization of registration

It occurred to me that enlistment via context "backflow" ought best to 
be addressed in WS-CF.

Greg

Green, Alastair J. wrote:

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