[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-caf] ACTION for optimization of registration
Apologies for multiple replies. Inline comments: Green, Alastair J. wrote: >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. > > > No argument here; that was a mistake on my part. >(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.) > > > I don't see any obvious reason to allow refusal either. >You can obviously handle that vectorization in WS-CF. > > > Yep. >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. > > > Right. Seems as though this is a distinct optimization and not generally applicable. Why not provide both, at both levels (CF, TXM)? >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)? > > > What is "checked"? >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. >> >> >> >> >> > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]