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

[Greg Pavlik <greg.pavlik@oracle.com>]

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