Re: question about transaction operation in ForCES protocol draft!

JiaFenggen <jfg6688@hotmail.com> Mon, 24 December 2007 01:50 UTC

Message-Id: <MON.24.DEC.2007.095035.0800.>
Date: Mon, 24 Dec 2007 09:50:35 +0800
From: JiaFenggen <jfg6688@hotmail.com>
Subject: Re: question about transaction operation in ForCES protocol draft!
Content-Type: multipart/alternative; boundary="_5c3ac7e1-676f-44ae-9112-9d6e352d07f3_"
MIME-Version: 1.0

If I understands all corretly,what chuanhuang arguing is how to handle transaction failure in Multi-FE enviroment. In my opinon,according to the forces protocol,in an multi-FE transaction,when all participating FE commit that they can do the transaction correctly,that is to say,when CE receiving  commit responses with operation result setting to success from all participating FEs,then the CE can make sure that the transaction is success and issue TRCOMP to clear the state in each FE,if one of the participating FE fails to handle the transaction,which is make sure by CE to receive a commit response message with operation result setting to failure,then the CE should send TRCOMP to all participating FEs with the transaction flag setting to ABT,which means to abort the transaction.

According to the original question,i think the first choice is correct,CE must send TRCOMP to FE in all casres.

Yours,Fenggen> Date: Sun, 23 Dec 2007 12:49:45 -0500> From: hadi@znyx.com> Subject: Re: question about transaction operation in ForCES protocol draft!> To: FORCES@PEACH.EASE.LSOFT.COM> > 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> > updat> > 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 inconsist
 ent if CE don'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 unnecess
 ary for a> corner case (of only one FE in an NE).> > cheers,> jamal>
_________________________________________________________________
天凉了,添衣了,心动了,“七件”了
http://get.live.cn