Subject: Re: Nailing Down Of Transactions

From: Brian Rosen <[email-masked]>
Date: Thu, 2 Sep 1999 12:07:19 -0400

Yeah, I had the same problem, and came to the same conclusion
    Wildcarded commands are attempted for all terminations matching the
        wildcard
    Commands after a failed command are not attempted
 
I'm still ambivalent about attempting all wildcard matches.  I'll give you
one reason to do so: if you stopped at the first failure, how would the MGC
rerun the command after figuring out what to do?  It can't repeat the
wildcard , it would have to audit to find all the matches, and construct a
command with each match individually.
 
I believe we should make a statement that says "the order of execution of
the terminations matched by a wildcard is not defined".  Either that or
define that they are always done in (alphabetical??) order.
 
Brian

-----Original Message-----
From: Rex Coldren [mailto:[email-masked]]
Sent: Thursday, September 02, 1999 11:27 AM
To: [email-masked]
Subject: Re: Nailing Down Of Transactions

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: 

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. 

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 

Tom-PT Taylor wrote: 

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: Christian Groves <[email-masked]>
Date: Fri, 3 Sep 1999 15:49:40 +1000

With regards to the execution of terminations I think it makes a
difference to when a command fails and you have to return an error. The
MC needs to know which terminations the command was succesful, failed,
un-executed.

For example:
If a command is wildcarded -
If order 'not defined' then we have to return the list of terminations
that 'succesfully executed' followed by the 'failed termination' and
(I'm not sure about this) a list of non-executed. In the (o-) optional
case you'd only have to return the 'failed' terminations as it would be
assumed everything else worked. This would enable to the MGC to have a
complete picture. This could lead to rather large messages between MC &
MG.

If an order is assumed (some schema - numerical, alpha, interface groups
etc)
then you only need to provide the information about the 'failed
termination'. The MC could assume terminations previous to this were
executed and commands after were 'not executed'. In the (o-) optional
case all commands assumed to be 'executed' only 'failed' ones would be
be returned. This would provide shorter messages and less? parsing.

The how the ordering is done is determined by the MG. I gather this will
be agreed upon when  the MC/MG determine what the termination ID format
is.

Cheers, Christian