[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: FW: [ws-caf] ACTION for optimization of registration
thanks, I think this helps clarify alot of issues that have been going back and forth over the last week. Green, Alastair J. wrote: >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]