[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [bt-spec] Re BTP Issue 103 (was issues 100, 101, 103 and 105)
> The existing specification text is implementable, and produces a desired > behaviour which helps to enforce transactional integrity. I would hope so given the effort expended so far. However, our proposed change would not affect this at all - if it did then I would certainly consider removing it or at least leaving it to later. > It can, at some level, be reasonably criticized: you could make a case for > splitting CONTEXT into ENROLLEE and CHECK, and renaming CONTEXT_REPLY to be > CHECK_REPLY. Then you would never see checking info (i.e. the reply address) in > ENROLLEE, and explicit control over checking would become possible (send > ENROLLEE only, or send ENROLLEE & CHECK). You could certainly make an argument for this, but we're not proposing going even that far. All we are proposing is removing the CONTEXT message entirely from the BTP "protocol layer" (bad name, but basically we mean that part of a "system" that is purely involved with talking to the coordinator(s) and not involved with application specific interactions). This should be a single change in the specification: - add CONTEXT (or the information that is embedded within CONTEXT) as the payload within the BEGUN message. If there is no CONTEXT then we have the BEGUN as it currently stands. Thus, CONTEXT as a message only ever appears within application messages. > However, it appears to us that checking is a 95+% case in this environment, and > that the weight of a single excess element (which is not present when not used, > i.e. in the BEGIN/BEGUN and Cohesion CONTEXT propagation cases) is not a great > overhead or trouble. I think you've got the wrong end of the stick. We are not pushing for removal of any messages or their functionality. > Our view, for what it's worth (2/20 votes), is that change in this area would be > possible, and even theoretically sweet, but is not strongly justified at this > stage in the life of the spec. We also suspect that implementation/deployment > experience would assist in further evaluating the type of change envisaged. This is based on implementation/deployment experience. Obviously the more implementations that are out there the more experience gained, but we're not coming at this from the "theoretical" stand-point. > So, I would propose "defer" as the solution to the this issue. I don't think this is a big issue and we can certainly live with it either way. However, if we are to change it, we'd prefer to do it now and not have to worry about any legacy implications. > > It would be useful to see a concrete textual alternative, with all of its > ramifications worked out, if another resolution is proposed. See above. Mark. ---------------------------------------------- Dr. Mark Little, Distinguished Engineer, Transactions Architect, HP Arjuna Labs Email: mark_little@hp.com Phone: +44 191 2606216 Fax : +44 191 2606250
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC