Re: question about transaction operation in ForCES protocol draft!

[Chuanhuang Li <[e-mail]>]

Dear jamal:    Thanks very much!    The following is my viewpoints:1:As you said,yes,a single FE on the NE is just one case.But what I said is also fit for multiple FEs. 2:Only the FEs which executed the transaction messages successfully wait for the TRCOMP.The FEs which failed will clear the state they have kept immediately ,because the information which they have saved for possible rollback is useless,and thay needn't wait for the TRCOMP. 3:The CE needn't tell the FE "please purge state on failure without waiting for TRCOMP".For multiple FEs:   The whole transaction failed,if CE recevied one COMMIT-RESPONSE message which indicated the execution failed from any FE.in this case,CE only need send COMMIT message(abort) to the FEs which executed successfully,it needn't send the TRCOMP!   The whole transaction succeed,if CE recevied COMMIT-RESPONSE message which indicated the execution succeed from all FEs!in this case ,CE need send TRCOMP to all FEs.For sigle FE:   It is the sam
 e with multiple FEs.If CE received COMMIT-RESPONSE message which indicated the execution failed,it needn't send the TRCOMP!    Best regards!                                                                                      Chuanhuang Li                                                                         Zhejiang Gongshang University.China                                                                                    12/24/2007

> Date: Sun, 23 Dec 2007 12:49:45 -0500> From: [e-mail]> Subject: Re: question about transaction operation in ForCES protocol draft!> To: [e-mail]> > On Sun, 2007-23-12 at 21:03 +0800, Chuanhuang Li wrote:> > Thanks for your answers!> > > > We are implementing ForCES protocol as the general protocol stack,so> > we should consider all the possible situations.> > > > First,there have transaction operation between CE and one FE,and we> > shouldn't limit user use it since the Protocol supported.> > in draft:(page 21)> > As defined above, a transaction is always atomic and MAY be> > a. Within an FE alone> > Example: updating multiple tables that are dependent on each> > other. If updating one fails, then any that were already> > updated> > must be undone.> > b. Distributed across the NE> > Example: updating table(s) that are inter-dependent across> > several FEs (such as L3 forwarding related tables).> > > > Sencod,You said:it would be inconsistent if CE do
 n't send the TRCOMP> > message in that case.I don't agree.Exactly,it lied on the user's> > implementation of the protocol.Also,i think it is a redundant> > operation for CE to send TRCOMP,if the CE received the COMMIT-RESPONSE> > message which indicated the transaction failed.> > If i am not mistaken you are not arguing against the case of more than> one FE in the NE (in which case one FE may fail but N others succeed). > You are just saying that for a case of a single FE on the NE, the TRCOMP> is redundant. > Which brings up my concern on consistency:> How do i (as FE) know you that in certain cases you are not going to> send me a TRCOMP (when there is only one FE in the NE)? remember the CE> is the smarter of the two; as an FE i am dumb. The CE knows there is> only one FE in the NE; but how does such knowledge get propagated to> tell the FE "please purge state on failure without waiting for TRCOMP".> We could introduce additional signaling, but that is unnecessary for a> c
 orner case (of only one FE in an NE).> > cheers,> jamal>
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/