[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: verbatim notes from London bt models meeting
Peter, you are right. There was an in-built assumption in the BEA's submission that the vote on the outcome already occurred, in-built to the application message exchange. I am open to consider another use-case, when the vote should be part of the completion protocol. As far as time-outs on the ability to compensate, I think this should be bundled in with the timeout for the bt (cohesion). If a participant is willing to take part in a bt, then it should guarantee that it will be able to compensate until the bt end or times out. Pal > -----Original Message----- > From: Peter Furniss [mailto:peter.furniss@choreology.com] > Sent: Thursday, April 05, 2001 4:35 AM > To: Models Bt > Subject: Re: verbatim notes from London bt models meeting > > > This was going to be my comments to Sazi on his clarifications, but since > I've now circulated those notes, it's probably better to discuss > this here. > > I think there is a bit of a difference of thought and it's worth sorting > out. > > We were considering that the recipient side could *choose* to > implement its > part in the action as if it were an ACID transaction - e.g. would directly > use its transaction service, treating the cohesion as the superior, and > using a regular XA database to hold the data. The > termination/commit/cancel > message of the cohesion/business transaction is mapped to the > xa_commit. If > it does this, obviously it does make the data subject to locks, but > essentially, it owns the data and it can decide whether this is > acceptable, > even for a longer time than is normally considered acceptable. > > Meanwhile, another service in the same cohesion might *choose* to > implement > using a complete-now-but-allow-for-compensation approach. In this case, it > might make the initial application of the operation a proper transaction, > and the compensation (if it happens), another transaction. > > The mechanisms used would be considered internal to the service. But those > in London wanted the first to be possible. > > I think this effectively means we are looking at a two-phase exchange (I > think this was the assumption of those physically at the meeting, though I > don't remember it being stated quite that directly). But a two-phase > exchange (meaning just "can you do your part ?", "yes", "then let it be > done"/"dont do it after all") is inevitable if we are to have any level of > atomicity or consistent application of operations anyway. > > [ In fact, it seems to me there is an implicit two-phase exchange in the > original BEA submission, but the equivalent of the vote is carried in the > application replies, with the prepare implicit in the message itself. > Without this assumption, there is no way the initiator + main coordinator > side to know what is being committed. } > > > > Separately - most of the timelimits discussion was on the > possibility of the > compensation itself having a limit, as in reservation situations, > where the > reservation is held for some period and then service will decide > for you if > you haven't got back to them. I don't think this can be avoided > - it's just > the way some people will do business. If the timeout is hit, then it does > rather break the model (it's similar to heuristic decisions, but at least > there can be prior warning in this case). > > We definitely did not come to final conclusions on timeouts. > > > > Peter > > > -----Original Message----- > > From: Sazi Temel [mailto:sazi.temel@bea.com] > > Sent: 05 April 2001 04:26 > > To: Peter Furniss > > Subject: RE: bt models london minutes/notes > > > > > > > > Including again.. just tried to clarify a few comments I have > made during > > the meeting, if you still do not get the attachment, no > problem. I am sure > > I will get another chance! > > > > --Sazi > > > > At 01:08 AM 4/5/01 +0100, you wrote: > > >Sazi, > > > > > >No attachment arrived at me - I just saw the statement that it had been > > >converted (as below). > > > > > >Your message crossed with the reworked summary I sent out, in > > which I tried > > >to summarise what I thought was the consensus. I'm sure you'll > > say if it is > > >still wrong. > > > > > >Mark - what shall we do with the detailed notes ? > > > > > >Peter > > > > > > > > >> -----Original Message----- > > >> From: Sazi Temel [mailto:sazi.temel@bea.com] > > >> Sent: 04 April 2001 21:18 > > >> To: Peter Furniss; Little Mark > > >> Subject: Re: bt models london minutes/notes > > >> > > >> > > >> > > >> Peter, > > >> Included a modified version of the doc that you have sent -I just > > >> clarified > > >> what I said during the meeting (see marked >>> text in the > > doc). Thanks. > > >> > > >> --Sazi > > >> > > >> At 06:28 PM 4/3/01 +0100, Peter Furniss wrote: > > >> >This is what I typed during the meeting. Please comment (cc > > >> Mark) if I have > > >> >traduced or misrepresented you. I tended not to include > > things when I was > > >> >directly involved. > > >> > > > >> > > > >> >Peter > > >> > > > >> > > > >> >------------------------------------------------ > > >> >Peter Furniss > > >> >Choreology Ltd > > >> > > > >> >email: peter.furniss@choreology.com > > >> >phone: +44 20 7670 1679 > > >> >direct: +44 20 7670 1783 > > >> >13 Austin Friars, London EC2N 2JX > > >> > > > >> >Attachment Converted: > > "c:\data\email\attach\London_april_minutes_am.doc" > > >> > > > >> > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC