Subject: Re: Nailing Down Of Transactions

From: Nancy-M Greene <[email-masked]>
Date: Thu, 2 Sep 1999 12:52:50 -0400

Rex, then we need two ways of handling a transaction. If we keep the
definition that subsequent commands in a transaction are not executed if one
command fails, then you also need a way for an application to mark a command
in a transaction that should NOT cause execution of subsequent commands to
stop if it fails. 

To do this, we need to go back to the concept of an "optional" command.  In
ABNF, you mark the command name with O-. For example, O-Modify, where the
modify attempts to put call display information out on the termination. If
it fails, subsequent commands in the action, and subsequent actions in the
transaction should continue.

Nancy
--------------------------------------------------------------------------
Nancy M. Greene 
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:[email-masked]

> ----------
> From:         Rex Coldren[SMTP:[email-masked]]
> Sent:         Thursday, September 02, 1999 11:27 AM
> To:   [email-masked]
> Subject:      Re: Nailing Down Of Transactions
> 
> Tom, 
>    I'll point out that what you have proposed differs slightly from what
> we 
> have had in the protocol since March.  The point of difference appears to 
> be sentence two of point three: 
> 
> 3. Transactions are executed on a best-effort basis.  That is, every
> command 
> is attempted, regardless of failures of preceding commands.  (Obviously 
> execution of a command with a dependency on the outcome of a previous
> failed 
> command may terminate after that dependency is discovered, without going
> too 
> far into execution.)  Where '*' wild-carding is used for a terminationID, 
> every instance shall be attempted. 
> 
> I'm not sure that attempting commands following a failed command is such a
> 
> good idea.  It is quite possible that the outcome of the commands
> subsequent 
> to a failed command will be unexpected and may make unwinding more 
> difficult than if the subsequent commands hadn't been attempted.   I would
> say 
> that we keep the original rule (i.e.-commands following a failed command
> are 
> not executed).  The wildcard is really the oddity here since it can be
> considered 
> simply shorthand for a sequence of commands where the order is not
> actually 
> defined.  Allowing the wildcarded command to finish after the point of
> failure 
> in the command is really the question.  I'm ambivalent there, but it looks
> 
> like you want the wildcard to continue to completion regardless of failure
> of 
> one or more parts of that command.  I still prefer stopping execution
> after a 
> failed command, but could accept that a wildcard is a special command that
> 
> should be allowed to complete.  The commands in a transaction following
> the 
> failed wildcard should not be executed. 
> 
> Rex 
> 
>

---

From: Rex Coldren <[email-masked]>
Date: Thu, 2 Sep 1999 11:18:08 -0700

Nancy,
   I wouldn't say we "need" a way for an application to mark a command in a
transaction that should NOT cause execution of subsequent commands to stop
if it fails.  That sounds more like a nicety to me, and I don't care one way or
another whether we have it (i.e.-I am not voicing either support or opposition).

Rex