OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-models message

[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