[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-caf] ACTION for optimization of registration
Mark Little wrote: > > > Greg Pavlik wrote: > >> 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. > > > Actually I think that we have two different ways of approaching the > same problem. > > (i) a WS-Context context that flows back on the response; none of our > specifications actually restrict context flows on "outbound" messages, > since we're in a one-way domain, and this is conceptually appealing as > it continues to tie together message exchanges within the same > activity because the messages are all contextualised. Put it another > way: all one-way messages are contextualised and we are simply > providing another specific element within the extension capability we > already support, to address this. The precedent for this is the OTS > and various commercial implementations. > > (ii) a "boxcar" (a la BTP) of enlistment messages that accompany the > one-way "response" message. The precedent for this is BTP. > > Now it seems to me that (ii) could be dealt with by the underlying > SOAP infrastructure - that's always been the argument against putting > boxcarring into the protocol. Whereas (i) is a specific approach for a > very specific problem. > > Pros and cons both ways. > >> >>> (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. > > > Agreed. If it's an optimisation that MAY be used, then that means that > endpoints don't have to accept it. > >> >>> 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)? > > > I agree and think it is a separate discussion item. Let's try to keep > this discussion on the subject of the original issue which was > accepted at the face-to-face and address other optimisations separately. > >> >>> 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'm not certain it belongs in WS-CF. "checked" is something that is up > to the Referencing Specification to define, not the general > coordination/registration framework we have. As an example, the OTS > describes several ways of doing checked transactions and does not > mandate any specific implementation: it simply recommends the X/Open > XA version. > >>> 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. >> >> > Agreed. > >>> 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)? >>> >>> >> >> > Another issue IMO. Let's keep this particular discussion in the realms > of the original issue please. > >>> >> What is "checked"? > > > Don't you have that AI ;-)? > I'm not asking "what are checked transactions": I wanted more detail on what Alastair has in mind as far as specific messages and optimization techniques. This also relates to the earlier discussion of (pre) identifying transaction participants as I (now) understand it. > Mark. > >> >>> 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]