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

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Fw: implicit prepare - sent on behalf of Savas


<I'm sending this for Savas again - Mark>

Peter,

> 
> With any kind of filter/interceptor setup (compare OTS implicit
> propagation), it would seem quite reasonable at least for upcoming
Enrolls
> and Votes to get stripped off an application response and delivered to
the
> Coordinator.  By the same token, there is no inherent reason why
messages
> from the coordinator could not be sent down with an application
request -
> the issue would only be whether the coordinator can know it's
appropriate
> to
> send the message.

I don't know how traditional TX systems are implemented but I can see a
problem with this approach. Imagine an implicit prepare message being
sent together with the first application message to a service. If the
implicit prepare message is intercepted and delivered to the coordinator
(the one that knows about participants) then a race exists. The prepare
message may be delivered to the coordinator before any participants are
registered. The coordinator cannot wait until all the participants are
registered because it just doesn't know how many there are going to be.

> 
> In particular, it would seem reasonable for an initiator to indicate
that
> the current request is the last application message that will ever be
sent
> to this service (a) - this is something that the initiator (and only
the
> initiator application) can know of itself.  But if the service
receives
> such
> an indication, and has sent what it thus knows to be the last
application
> reply, why should it not vote ?  It will never receive anything that
will
> make it more able to get into a ready state.
> 

Agreed. However, the initiator cannot indicate that it is sending the
last application message to the service aiming to get an implicit vote
from the participants because the service may not be able to inform all
participants registered with the atom (it just doesn't know how many
have been registered). If the implicit prepare message is intercepted
and sent to the coordinator then we don't gain anything in terms of
message exchange because now the coordinator will need to request votes
from all participants.

> 3) It is true that only the coordinator knows the true topology of the
> atom
> (i.e. what participants are enrolled), and it therefore has the
> responsibility for ensuring the atom is unanimous. However this only
means
> that it must ensure it does get a vote from all participants, not that
it
> can't accept a vote from a participant well before the initiator has
told
> the coordinator to get votes from everyone.
> 

No objection there.

> 
> Let us allow the initiator to send a marker to a service meaning (a)
as in
> 2) above, at any point where the initiator knows this to be true, and
from
> that allow the service (after making what data changes it determines
are
> appropriate) send a definitive vote with the reply. The vote is
stripped
> off
> (by some means - effectively part of the initiator/communication
boundary)
> and delivered to the coordinator.

But it is not the service that is voting. It is the participants that
happened to get registered. The service may not know the participants
(see also bellow).

> 
> Eventually the initiator/terminator will ask the coordinator what the
> atom-wide vote is (this will often be intermediated by a cohesion
entity,
> but not always). At this point the coordinator should send a prepare
(with
> at least sense (h)) to any registered participants that haven't sent a
> vote.

Again, no objection there.

> 
> The initiator doesn't know exactly where, or how numerous (0..n) the
> participant(s) is that is registered as the result of propagating the
> context to a service. The initiator can (and usually does) know what
> messages it is sending to that service, and when they form a complete
set
> on
> which the service, and any underlying participants, can determine
their
> vote.
> 

You're assuming that the communication between the service and the
participants allows such information to be propagated. Let's imagine one
service that accepts two different application messages from one
initiator within the context of the same atom. The first application
message causes participant A to be registered with the coordinator of
the atom. The second application message causes participant B to be
registered with the coordinator. The second message carries an implicit
prepare. How is the service going to contact participant A? Do we assume
that the service has the means? Does it keep track of what is
registering with the coordinator?

> > think instructing a Participant to vote and then receiving the vote
is
> > the solution. Even if it is an indication that it could vote rather
than
> > an instruction, I believe it is wrong. Participants should only send
the
> > vote to the Coordinator and not to the Initiator/Terminator and they
> > should only receive a request for a vote from the Coordinator.
> 
> why is the latter (especially as just an indication) "wrong" ? This
isn't
> a
> moral issue :-)
> 

It is immoral and unethical :-)

In terms of the message sets and interactions that we are specifying, I
believe that the Initiator should not receive votes directly. If it
contacts the Coordinator to get the vote, then I am in no disagreement.
You too agree on this.

> > The solution would be to allow the Initiator/Terminator to issue a
> > request for a prepare on the Atom. Since the call to the Web Service
> 
> we need to be able to do sequential multiple one-shots in  a single
atom -
> posit a transfer where there is a one-shot to get a value from service
A
> and
> then to deliver the value (or a derivation of it) to service B. That
> requires that A is prepared before B has been invoked.
> 

So we make A and B atoms as well and we call confirm on A before we pass
the message to B. Since these are sub-atoms, everything should work just
fine.

> >
> > Note from Mark: apparently Savas has tried to send this several
> > times to the
> > list and no error has occurred at his end, but nothing has turned
up. Do
> > anyone know if there are any problems with the mailing list?
> 
> I've had no trouble.

I never had to send a message to this list and only late last night I
received the error messages from my attempts to post. I was registered
with a different email address than the one I normally use :-(

.savas. 





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC