Subject: Re: Nailing Down Of Transactions

From: Fernando Cuervo <[email-masked]>
Date: Thu, 2 Sep 1999 11:07:22 -0500

Rex, All,

I agree, the best effort concept in general is not useful to solidify the
semantics of transaction processing. I would still want to keep the wildcard
to do all that it can, since there is no implied order in the treatment of a
wildcard (or is there an assumption about this?) I'm  copying below a
response I just sent to the list since is related to this discussion:

Well, even in certain cases where you "succeed"  the interpretation the
scope of the wildcard will be different in the MGC and the MG, you will end
up doing an audit anyhow. As we can see from the discussion, the concept of
transaction success/ failure is surely drifting away from the classical
definition of a "flat" transaction, certainly some of the discussion on the
topic shows glimpses of the nested and chained transactions that have been
used for many years.  I'm not advocating the generalisation of Megaco to do
all these things, but I believe that transactions with o- optional commands
is  a small increment that complements well the original flat transaction
model that we wanted to adopt. As far as the success/failure stuff, we could
use a single term: "response", there is no need to differentiate between one
and the other since the syntax is the same and the processing is the same:
for a "success" you still have to go and collect for each command in each
action the returned parameters, in a "failure" you find an error code!. So
the proposal is:
1-keep the transaction flat with o- type commands
2-unify reject/accept into "response"

Fernando Cuervo 

> ----------
> From:         Rex Coldren[SMTP:[email-masked]]
> Sent:         September 2, 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 
> 
> Tom-PT Taylor wrote: 
> 
>       Nancy and I have had further discussions.  The proposed resolution
> to the 
>       transaction issue is as follows: 
> 
>       1. The transaction provides a means of grouping and ordering
> actions.  It is 
>       also the unit of response. 
>
>       2. Actions shall be executed in the order in which they are
> presented in a 
>       transaction.  Commands shall be executed in the order in which they
> are 
>       presented in an action. 
> 
>       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. 
> 
>       4. There are three possible transaction responses: OK, pending, and
> error. 
> 
>       OK means that every command executed successfully.  The response may
> still 
>       have to be parsed to recover identifiers substituted for wildcards. 
> 
>       Pending buys time.  Do we need a time estimate, or will we say that 
>       transaction pending has to be issued often enough to reset the
> transaction 
>       timer at the issuing end before it expires? 
> 
>       Error means that there was a failure within at least one action in
> the 
>       transaction.  Detailed parsing of the response is necessary to find
> the 
>       failures. 
> 
>       5. As agreed before, the only atomic unit of execution is the
> individual 
>       command operating on a single termination.  That means that if a
> command 
>       attempt fails, the MG is responsible for ensuring that its state is
> restored 
>       to the state existing previous to the attempt to execute the
> command. 
> 
>       Tom Taylor 
>       Advisor -- IPConnect Standards 
>       E-mail: [email-masked] (internally, Tom-PT Taylor) 
>       Phone and FAX: +1 613 736 0961
> 
>

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 2 Sep 1999 14:22:37 -0400

From past experience with IPDC, I'm pretty sure the O- option will never be
used in practice, but I can live with it if other people can.

> -----Original Message-----
> From: Greene, Nancy-M [CAR:5N10:EXCH]
> Sent: Thursday, September 02, 1999 12:53 PM
> 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]
>
> > ----------
> > Sent:         Thursday, September 02, 1999 11:27 AM