[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [ws-caf] ACTION for optimization of registration
The following e-mail to Greg was intended for the list too, but I hit the wrong version of reply. I recapitulate the well-known notion of checking (known well to Greg as well, I know!) in order to explain my points about the separate significance for checking of a BTP-style context reply, and my point about inferior identities. Alastair -----Original Message----- From: Green, Alastair J. Sent: 12 July 2005 22:03 To: 'Greg Pavlik' Subject: RE: [ws-caf] ACTION for optimization of registration Hi Greg, The concept of checking is an interaction between the app and the transaction sub-system. If the application can be confident that all potential "participants" (cd be sub-coordinators too) are present, known to the root coordinator (either directly, or transitively to the sub-coordinators known to the root coordinator, yea unto the last generation, i.e. all the way down the tree to the leaf nodes), then it is safe for the application to request confirmation/commitment. If this knowledge is not present then the application risks pushing the two-phase exchange downtree in a race with the enrolments/registrations etc coming uptree. If potential participants are not known when the 2pc exchange propagates downtree then some may be ignored, and can become orphaned, waiting for communication relating to transaction outcome that will never arrive. The application is said to "check" that all potential participants are present, before permitting itself to initiate confirmation/commitment. There are two ways of achieving checking in a distributed tree. You can define a special message (a supplement to transactional application requests' responses) which means: "I have registered or enrolled all possible participants that must be part of the two-phase outcome as a result of the request that was sent to me earlier". At a more general level we could say: "all participants for the referencing spec's protocol are present": this statement could legitimately be made at the WS-CF level. Or you can count or check the enlistments to ensure that they are correct in number, or in number and identity, against some expected population of inferiors. Which brings us to another sub-issue that Mark questioned: why do we need a way of identifying inferiors? If the EPR mechanism has no means of communicating an application identity which can be understood, under some application contract, by both application elements (client/server, requester/responder or however you choose to model it), then it is not possible for the second method of checking to be supported, because the coordinator cannot present to the terminating application element a comprehensible view of the identity and number of the necessary inferiors. Note (in this respect) that a terminating application (the one that says "commit" in an ACID context) could legitimately exclude, rebuff or ignore unwanted or non-critical enlistments. As I understand WS-Addressing, the reference properties are defined to be opaque to the receiver: in other words they must be represented as part of the address in back-communication, so that the publisher of the address can map the back-message (reply if you like) to an internal endpoint which "lies beyond" the ostensible transport end-point, but no reliance or interpretation can legimately be put upon these properties for application-level correlation. However, for the purpose of checking (and in cohesive outcomes, for differential, mixed confirm/cancel sets) it is necessary to correlate the enrolments or enlistments with application identities. Concrete example: solicit quotes from JPM, Nomura and ABN Amro. Decide that at least two must be present to go ahead with confirmation. Decide that at least one must be JPM (we want to do business with them). How can the terminator tell that JPM is present in the enrolment set before going ahead to commit? For this purpose an application identifier must be presented with the enrolment. It is not part of the EPR per se, at least if the WS-A opaqueness rule is observed. Ergo, we need the BTP concept of an inferior name, as well as an inferior identifier (EPR). This is a rather rushed concentration of argument, so forgive me if it is, in turn, a bit "opaque". Alastair -----Original Message----- From: Greg Pavlik [mailto:greg.pavlik@oracle.com] Sent: 12 July 2005 20:43 To: Green, Alastair J. Cc: Mark Little; ws-caf 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]