Subject: Re: transaction in H.248

From: Brian Rosen <[email-masked]>
Date: Tue, 16 Nov 1999 15:06:30 -0500

Hmmm, not quite right

See below marked [BR]

> -----Original Message-----
> From: Vikas Bansal [mailto:[email-masked]]
> Sent: Tuesday, November 16, 1999 2:40 PM
> To: [email-masked]
> Subject: Re: transaction in H.248
>
>
> Wai-tak Siu wrote:
>
> > Hi,
> >
> >     I have a few questions on how transactions are handled in error
> > cases.
> >     Scenario: A transaction consists of multiple commands, and the
> > transaction processing stops at the last command that generates an
> > error, unless the command is optional.
[BR] Well, it stops on the first command not marked optional
that has an error.

> If a command is marked "optional", it means that the command
> may be executed
>
> even if a previous command results in an error.
[BR] This is incorrect.  The command marked option means even
if it causes an error, it is safe to continue executing
commands

> So in case of
> an error,
> stopping the transaction processing does not depend on
> whether the erred
> command is optional or not, it only depends on whether the subsequent
> command(s) are optional. Rephrasing ur sentence
> "A transaction consists of multiple commands, and the
> transaction processing stops at the last command that generates an
> error, unless the SUBSEQUENT command(s) are optional AND
> gateway decides to
> execute these optional commands".
Nope, it's "A transaction consists of multiple commands,
transaction processing stops at the first command not marked
as optional which generates an error"

> > The commands before the one that
> > generates the error are not rolled back.
[BR] Correct.
> ok.
>
> >
> >     Question: Is the command that generates the error atomic, and
> > treated as if it has not been processed? Specifically, if
> this command
> > contains an EventDescriptor, will it not replace the
> existing one at the
> > termination?
>
> Gateway implementation should take care that any command
> which results in a
> an error does not have any side effects. I suppose thats the
> way it should
> work. The draft is silent about this.
[BR] Yep, because it was considered too hard to insist on this.
An example would be a Subtract which used a connection oriented
protocol.  If you get an error taking down the connection, it's
going to be down, and you can't put it back!
> >
> >     Making it a bit more complicated... If the command applies to
> > multiple terminations, and the command fails only at one
> termination T.
> > I suppose the descriptors of this command still apply to all
> > terminations other than T, and the whole transaction is
> stopped. Is my
> > interpretation correct?
>
> The draft says "if a command contains a wildcarded TerminationID, the
> command is attempted with each of the actual TermIds matching
> the wildcard.
> A response within the TransactionReply is included for each
> matching TermID,
>
> even if one or more instances generated an error".
> So, ur interpretation is correct that the descriptors of the
> command spplies
>
> to all terminations other than T.
[BR] Yes, this is correct.  Wildcards are treated as a shorthand for
multiple commands in an Action with identical parameters.

Brian

---

From: Vikas Bansal <[email-masked]>
Date: Tue, 16 Nov 1999 15:17:21 -0500

u r right. The earlier version carried the interpretation of "optional"
that I had mentioned.

Regards
Vikas