Subject: Re: T13) Transactions - allowing optional commands

From: Brian Rosen <[email-masked]>
Date: Fri, 13 Aug 1999 10:42:57 -0400

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: David Oran <[email-masked]>
Date: Sun, 15 Aug 1999 09:00:25 -0400

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.

> From: Media Gateway Control (megaco)
> [mailto:[email-masked]]On Behalf Of Brian Rosen
> Sent: Friday, August 13, 1999 10:43 AM
> To: [email-masked]

---

From: Stephen Terrill <[email-masked]>
Date: Sun, 15 Aug 1999 23:59:25 +0200

Hi,

I think that in addition to considering that the tone could be sent to a subscriber, one should consider that the tone could be a DTMF tone sent to specialized equipment (IN service with DTMF reception, a bank etc).  The MGC should be aware of what was sent and what wasn´t sent.

In addtion to that, there is the scenarios where the bearer control (e.g. PNNI for ATM) is in the media gateway, and the subtraction of a termination will result in a release of the resources.  This cannot be "un-released" (those resources may already be re-used in the network immediately).

I think that these concepts lead to the need for the optionality in the commands and/or the ability to be able to indicate where the command processing stopped.

Regs,

..//Steve