Subject: Re: T13) Transactions - allowing optional commands

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 23 Aug 1999 09:47:11 -0400

No, this hasn't quite been beaten to its knees.  In our original intent,
transactions had three roles:

(1) as an atomic element of execution.  That is the aspect that seems to be
discredited.
(2) as a semantic unit defining the order of execution of the commands
contained therein.  We still need to discuss this one.
(3) as the unit of application-level acknowledgement.  This also needs to be
discussed.

Regarding (2): there are two points to think about.  One is that there may
be dependencies between individual commands.  The second is that we also
have another unit of grouping: by action or context.  There could be
dependencies between actions.  I'm mulling over the call waiting case in my
mind, to see if it provides an illustration of this, but I haven't come up
with anything yet.

Regarding (3): we have a choice between the command, the action, or the
message as the unit of acknowledgement.  Whichever we use has to be uniquely
identifiable in the response.  This doesn't introduce anything new in
principle.  We also have to bear in mind the different lengths of time that
different commands may take to execute.  The unit of acknowledgement affects
message volumes and what records the issuer of a command has to maintain.
There's a tradeoff here: smaller acknowledgement units may mean increased
acknowledgement message volume, but the command issuer can release records
sooner.

> -----Original Message-----
> From: Michael Thomas [SMTP:[email-masked]]
> Sent: Sunday, August 22, 1999 3:33 PM
        [[TomT]]  ...
>     I'm not sure if this horse is well beaten by
> now, but I'd like to point out that this entire
> issue with transactions is really scripts in
> disguise: a script can be defined as a sequence of
> commands which can have conditional branching on,
> including error conditions.
        [[TomT]]  ...
>   I propose that
> we honor that decision and that we remove the
> Transaction language as Nancy proposes and define
> a new keyword/semantics which says that a message
> can contain multiple commands, but there is no
> implied relationship between the commands. If an
> MGC wants finer control of intra-command errors,
> it MUST NOT group them into a single message.
>
        [[TomT]]  ...

---

From: Michael Thomas <[email-masked]>
Date: Mon, 23 Aug 1999 16:55:26 -0700

> acknowledgement message volume, but the command issuer can release records

   If ACK's are moved up to transaction level,
won't that break use of SDP? Eg, if I had a
transaction which did Add Term1, Add Term 2 (say
for videophone), I'd expect to see two different
SDP announcements, one per Add. Another thing to
consider are command warnings like the digit map
thing we discussed last week. The MGC might want
to correlate which digit map failed, perhaps to
install a simplified (but perhaps less optimized)
digitmap.
   Hong Liu also brought up the case of failures
with wildcards, and how the MGC would learn of
that. This points at the action level as being the
least common denominator. In general, the MGC must
be able to recover from errors in such a way that
it exactly knows the MG state after the error.
I'm somewhat dubious that audit is a cure-all here
either -- errors are sometime transient, and audit
only covers the things that it covers. If it's
outside of the scope of audit, then the MGC must
reset the MG to a well known state (perhaps
through a ServiceChange).
   Clearly the MGC doesn't want to be flooded with
ACK's on every little piece of code that went OK,
so maybe the right thing is to allow the protocol
to return multiple status messages, perhaps even
to the action level, but require the MG (SHOULD or
MUST) to do message aggregation (eg, fold
redundant 200's into a single 200 from action, to
command, and perhaps to transaction).

                Mike