Subject: Re: T13) Transactions - allowing optional commands

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 19 Aug 1999 10:48:18 -0400

I know there are lots of messages following this one in the thread, but I'd
like to put forward a few points to see if we can agree on them.  Any of the
statements I list below is open for question -- this is not yet a finding of
consensus.

1. As Christian Groves proposes, command execution should be treated
atomically.  That means that if a particular command fails, the MG is
responsible for restoring the state it held prior to attempted execution of
the command.

2. It is desirable to have a mechanism which allows multiple commands to be
specified at once and also controls the order of command execution (because
commands can have side effects and dependencies).  Our Transaction mechanism
does this at a minimum.

3. There are two possible levels of command confirmation: syntactic (the
message up to that point was well-formed) and semantic (the command was
executable).  The intent of TransactionAccept is to signal that the complete
transaction was acceptable on both levels.

4. Here's the big question: if a transaction fails at some point, is it
simpler for the MG to restore its state to that prevailing at the start of
the transaction, or for the MGC to analyze the failure and take appropriate
action?  If the answer is that the MG can do it better, we should go for
transaction rollback in Brian's sense, leaving the MGC responsible only for
cleaning up external effects of the failure.

5. It's fairly clear that life is simplest when transactions are kept as
simple as possible.  Christian's wildcard failure example is only likely to
arise when setting configurations at the start of an association.  The MGC
is going to have to be able to recover from such a failure in any event by
breaking the transaction into multiple parts so as to bypass the point of
failure.

> -----Original Message-----
> From: David Oran [SMTP:[email-masked]]
> Sent: Sunday, August 15, 1999 9:00 AM
> To:   [email-masked]
> Subject:      Re: T13) Transactions - allowing optional commands
>
> Ah. I think I see the confusion. People in fact may not have the same
> operational definition of a transaction.
>
> Brian's definition is the looser version - that if an error occurs during
> the processing of one or more of the actions in a transaction, then the
> state of the system can be put back to where it was before you started
> executing the transaction.
>
> Thre is a tighter definition, the one used in some business, database, and
> realtime systems. That one says that no externally visible state changes
> may
> be made by a transaction which later aborts.
>
> Brian's example clearly would violate the tighter definition of a
> transaction.
>
> Perhaps (thinking optimistically) we could agree that if everyone thinks
> the
> looser definition of a transaction is appropiate for Megaco, then we could
> retain the "Transaction" semantics of megaco requests?
>
> Dave.
>
>
>
> > -----Original Message-----
> > From: Media Gateway Control (megaco)
> > [mailto:[email-masked]]On Behalf Of Brian Rosen
> > Sent: Friday, August 13, 1999 10:43 AM
> > To: [email-masked]
> > Subject: Re: T13) Transactions - allowing optional commands
> >
> >
> > Let's take your example.  Tone on a line.
> >
> > Let's say the first command puts a signal on a line, and
> > somewhere down the list of commands, something fails.
> >
> > So you take the tone off the line.
> >
> > How long could it take you to process a "big" transaction?
> > 2 ms?  That would be a really, long transaction with a very
> > large number of commands.  Undoing tone on a line is trivial.
> > The only potential problem is the user hears a click.  If you
> > don't want that, then you implement the function "put tone on
> > a line" by doing all the processing except the actual switching
> > or tone generation, which you delay until you have processed
> > all the commands.  Then you whip through and finish.  Somewhat
> > extra work (breaking the processing in two pieces and keeping
> > a list of work to be done), but not at all onerous.
> >
> > There is just too little state to worry about here.
> >
> > What you need to do to convince me is describe some kind of
> > feature where you can't easily undo it, and can't easily
> > determine if the command would succeed without actually doing it.
> > I've tried coming up with one, but I haven't found any
> > such thing.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:[email-masked]]
> > > Sent: Friday, August 13, 1999 5:18 AM
> > > To: [email-masked]
> > > Subject: Re: T13) Transactions - allowing optional commands
> > >
> > >
> > > G'Day all,
> > >
> > > I think there are a few issues here.
> > >
> > > One is the rolling back of commands or as Brian puts it below
> > > 'undo any
> > > command in a transaction'.In theory it is certainly possible
> > > to do this
> > > in practise it doesn't always work. Think of tone generation
> > > once you've
> > > sent a tone how do you undo this???? That's why I think rollback isn't
> > > practical.
> > >
> > > Secondly, optionality - As Nancy mentioned below I put in a
> > > contribution
> > > in Berlin on having optionality of commands. This was brought in to
> > > start general discussion in the area of command handling. I think that
> > > you have to treat each command sequentially and atomically otherwise
> > > interoperability between different vendors may be
> > > 'interesting' if they
> > > parse commands differently.
> > >
> > > The discussion also raised the issue (Hong L) of how you handle the
> > > situation of a failed ADD on a wildcarded termination. eg. ADD(T*),
> > > T1-T30 succeed T31 fails. How do we report today that T31 failed? We
> > > might want the command to execute Add on T32-T60. You may not be able
> > > to roll back etc.
> > >
> > > So I support Nancy in saying that we need to review this area
> > > as I don't
> > > believe it works sufficiently today.
> > >
> > > Cheers, Christian
> > >
> > >
> > > Brian Rosen wrote:
> > > >
> > > > Could we have a wider discussion of why transaction syntax
> > > > is too hard to do?  I think this is not true; while not
> > > > trivial, I believe it is straightforward to undo any command in a
> > > > transaction, or do enough pre processing to know that the
> > > > transaction will complete prior to actual execution.
> > > >
> > > > I, for one, would like to undo this change made in Berlin.
> > > >
> > > > Optional commands are not required IMO.  Just make them separate
> > > > transactions.  Actually, it's not clear to me that if we
> > > > get rid of transaction syntax, that the whole transaction mechanism
> > > > should just be eliminated entirely.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Nancy-M Greene [mailto:[email-masked]]
> > > > > Sent: Thursday, August 12, 1999 2:59 PM
> > > > > To: [email-masked]
> > > > > Subject: T13) Transactions - allowing optional commands
> > > > >
> > > > >
> > > > > > T13) Section 6.4.1, 6.4.3.1,6.4.3.2, 6.4.3.3: Simplify
> > > transaction
> > > > > > semantics
> > > > > > - changes to text and to ABNF (Annex B) made: removed
> > > the concept of
> > > > > > rollback on transactions - the document did not define how
> > > > > you could roll
> > > > > > back commands that actually cause physical changes on
> > > the MG, e.g.,
> > > > > > sending
> > > > > > of a signal, subtracting a termination from a context.
> > > > > >
> > > > > > It was decided that in fact, all a transaction does, is
> > > ensure that
> > > > > > commands
> > > > > > occur in a particular order, and that no commands after a
> > > > > command that
> > > > > > fails, gets executed. In a TransactionAccept, need to say
> > > > > what a response
> > > > > > is
> > > > > > - added sentence on this. In a TransactionReject, the
> > > > > command that failed
> > > > > > has error code, all the rest of the commands are not executed.
> > > > > >
> > > > > >
> > > > > In Berlin, Christian Groves brought in a contribution asking
> > > > > for transaction
> > > > > to allow optional commands. I think this is something we need
> > > > > to add: We
> > > > > need to allow the failure of a command in an action to not
> > > > > stop execution of
> > > > > further commands in that action. Same thing for action: allow
> > > > > the failure of
> > > > > an action to not stop execution of further actions in the
> > > transaction.
> > > > > Christian Groves' example was that you might have 20 adds to
> > > > > do, and if one
> > > > > fails you still want the other 19 to go ahead.
> > > > >
> > > > > Here is another example:
> > > > > Transaction = 1 { Context = 2 { Add = $ {addparams}, Subtract
> > > > > = a5, Add = $
> > > > > {addparams} } }
> > > > > If the Subtract fails, you still want the second Add to occur.
> > > > >
> > > > > We propose adding an optional tag to each command, and to
> > > > > each context, for
> > > > > example:
> > > > > Transaction = 1 { o-Context = 2 { Add = $ {addparams},
> > > > > o-Subtract = a5, Add
> > > > > = $ {addparams} } }
> > > > >
> > > > > The o- on the Context says that if there were other actions in the
> > > > > transaction, they would be executed even if the action on
> > > this context
> > > > > failed. The o- on the Subtract means that commands after the
> > > > > Subtract are
> > > > > executed even if the Subtract fails.
> > > > >
> > > > > proposed ABNF:
> > > > >
> > > > > > ; This PR must contain at least one actionReject.
> > > > > > transactionReject =  RejectToken EQUAL TransactionID
> > > > > >                      LBRKT (actionReject|actionAccept) *(COMMA
> > > > > > (actionReject | actionAccept))
> > > > > > RBRKT
> > > > > >
> > > > > > ;This PR must contain at least one commandReject
> > > > > > actionReject =       CtxToken EQUAL ContextID
> > > > > >                      LBRKT (commandReject|commandAccept) *(COMMA
> > > > > > (commandReject | commandAccept
> > > > > > )) RBRKT
> > > > > >
> > > > > >
> > > > >         A further simplificaton would be that transaction
> > > > > just has one type
> > > > > of reply, called transactionReply - you really don't need
> > > > > transactionReject
> > > > > and transactionAccept - with this new sytnax they can be
> > > identical.
> > > > >
> > > > >         Same thing for action - instead of actionReject and
> > > > > actionAccept, we
> > > > > just need actionReply.
> > > > > >
> > > > > --------------------------------------------------------------
> > > > > ------------
> > > > > > Nancy M. Greene
> > > > > > Internet & Service Provider Networks, Nortel Networks
> > > > > > T:514-271-7221 (internal:ESN853-1077)
> > > E:[email-masked]
> > > > >
> > >
> >

---

From: Christian Groves <[email-masked]>
Date: Thu, 19 Aug 1999 17:57:29 +1000

G'Day,

Some comments on:
4. I think the MC is best to handle the failure case. If we parallel
this with ALF the reasoning behind ALF is that the application knows
best what to do in a failure situation. In the MC/MG case its the MC
that has the application and knows best what to do.

5. I agree that transactions should be simple as possible however the
protocol allows wildcarding at any point therefore we need to handle
this. If there's a failure when a wildcarded command acts on a number of
terminations we need to be be able to identify at which point it failed.
(probably relates to 3)

Cheers, Christian