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

[Mark Little <mark.little@arjuna.com>]

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. 
>  
>
I agree, and the word "context" was meant in the same way we use it in 
WS-Context: it says nothing about whether it is a full context, or 
simply a minimal context. At the f2f we discussed checked transaction 
semantics and that it something else we are looking at (I believe Greg 
has the AI for that).

>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).
>  
>
Understood. However, I think that is a separate discussion item.

>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.
>
Agreed. Although I mentioned that this MAY be something we want to have 
for each protocol (and the issue is currently logged against all of the 
protocols), the text provided is certainly WS-ACID specific.

> 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". 
>  
>
I think it's better to concentrate on the intent and make the text 
specific to each specification. Fairly obviously the intent is to ensure 
that no further work can be performed within the scope of the 
"transaction". How that is realised is going to be up to the 
specification, and in this case, WS-ACID.

>4. The last point again raises the need to identify
>inferiors/participants.
>  
>
I'm not sure I understand the problem. Participants are identified by 
their EPRs. This optimization does not change the identies of 
participants. The participantAdded message is a requirement for 
compliance with WS-CF and is simply an ack with OPTIONAL information for 
communicating with the coordinator (in this case). If the optimization 
is used, then an explicit participantAdded message does not actually 
flow from coordinator to registering service, but such a message will be 
expected.

Mark.

>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