[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: verbatim notes from London bt models meeting
Peter and Pal, I think we now agree on most of the things.. my comments are inlined below. --Sazi At 04:00 PM 4/5/01 -0700, Pal Takacsi-Nagy wrote: >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. Fully agreed. I think this may also solve the problem of how long a service will keep its promise (for example if one makes a query on availability of some goods, even after the reply sent, the promise made -have the goods you have requested- should be kept (as long as the transaction alive) until the bt times out or completes. Note that this is different than what I mentioned in the verbatim notes from London bt models meeting... This change is due to the fact that 1) keeping promise (holding data) as long as transaction is alive not necessarily implies any implementation such as data locking, need compensation (these all depends on the service), and 2) bt may need some kind of guarantee on outcome of the service operations which may be part of the protocol. <Yes, I have the goods you have requested means I have it and will hold it for you until transaction completes, if I cannot I will let you know (or you will discover this at the second phase?)> > >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. I agree. This is what I call a uses relationship - the cohesion is the superior, not necessarily managing the 2PC/ACID transaction of this particular service. By participating in a cohesion, the service commits to comply with the protocol (BTP) whether it implements/participates in a 2PC/ACID transaction or not does not matter and the initiator site does not know much about the services implementation - but one thing the cohesion knows is that the service understands the BTP and will execute accordingly. >> The termination/commit/cancel >> message of the cohesion/business transaction is mapped to the >> xa_commit. Does the service (lets assume a remote one) site maps the BTP words to XA words? or the initiator site (cohesion)? I have no objection if the service sites maps the BTP words to XA words, in fact this may be the case in many critical services. But if the initiator site maps the BTP to XA words then this looks like the cohesion is taking a XA transaction manager role for this particular service... which requires that there is an discovery (or by other means) of the type of the services offered (how would initiator know that a particular service implements 2PC/ACID transaction?) >> 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. >> I agree that a service can do anything it decides that is appropriate (as long as complies with BTP requests), it can lock data and uses 2PC/ACID etc. >> 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. >> Right. >> The mechanisms used would be considered internal to the service. Yes, the mechanisms are internal to the service. >> But those in London wanted the first to be possible. I am not excluding this possibility (of a service implementing/participating in ACID transaction) >> 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. } >> >> I am not, in any way, implying not to use two-phase exchange. I agree that there is a two-phase exchange and the vote on outcome is already occurred (in BEA BTP submission) thus if the bt commits, this particular service has already done its work (it may receive a notification on outcome of the BT, ie success/commit). In case of failure (it may receive a failure notification, ie rollback/reverse) it may use any means internal to the service to comply with the BTP. It may use compensation, rollback (if XA transaction) or any thing similar. >> >> 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