Subject: Nailing Down Of Transactions

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 2 Sep 1999 07:15:16 -0500

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: Rex Coldren <[email-masked]>
Date: Thu, 2 Sep 1999 08:27:23 -0700

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:

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