[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-caf] ACTION for optimization of registration
Good point. Mark. Greg Pavlik wrote: > 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. >> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]