[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