Subject: Command Atomicity and Rollback

From: Hemant <[email-masked]>
Date: Thu, 13 Apr 2000 09:48:09 +0530

Hi everyone,

    The discussions till date on the issue of rollback of command in case of its failure do not seem to lead to a clear consensus. Lets look at the issue from the point of view of both the MG as well as the MGC.     

    From an MG point of view, the MG will always have to maintain duplicate state information. One of the current state (after execution of descriptor) and another for what existed previous to it while executing the command. This would be a lot of overhead in terms of memory and implementation complexity. Also there might cases where rollback doesn't make sense (signals, event detection etc). Another clarification required is whether commands with embedded events and signals also be considered atomic? (in case the embedded signal or event encounters error, what will the MG rollback to)

     As far as the MGC is concerned, it wants to know the status of the termination on which command was executed. This can be determined by Auditing the termination.
    Another MGC concern may be that since the command can fail at any point, one would think that without rollback implementation, the MGC handling following a failed command would be very complex. The typical action of the MGC however in such cases is to follow up with an error treatment(like playing an error tone or taking the termination out of context or allocating some other termination etc). Will going back to the previous status really help the MGC implementation ? If the reason for rollback is to bring the termination into a state known to the MGC, it can be achieved by auditing the termination upon receiving the error response.

    Considering the above I would favour that rollback not be mandatory. Instead on encountering an error, the MG should stop further command processing. 

Any Comments ?? 

Regards,
Hemant 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hemant Kumar
Ficon Technology
E-mail: mailto:[email-masked]
Web: http://www.ficon-tech.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 14 Apr 2000 15:57:21 -0400

I've had this argument many times before, and always lost it, I think to the
determent of
both the protocol, and the resulting system.

First of all, you can't audit to find out the state of an MG to the level of
what happened on
a broken command without a pretty major amount of code.  I think it is
possible, but I think
it's hard.   There is transient state you would not reasonably be able to
figure out - a short
BRief signal, for example.

It is quite straightforward to build an MG to have "rollback" semantics,
even at the transaction
level.  It requires that you construct the code so that errors are
detectable before state is
changed, rather than after.  This is always possible - we only argue about
how hard it is.
It is also always possible to put state back, but I agree that it is
sometimes hard.

Certainly, at the level of a command:
    You should be parsing the whole command before executing any of it
    You should be checking availability of resources either simultaneously,
or
        prior to reserving them
    It should be straightforward to do all of the above before actually
doing state
        changes (reserving resources not counted as "state change")
    There are VERY few non-fatal errors that are not detected by the above,
that
        would cause a rollback problem.  Might be a couple, but special
casing them
        should not be very hard.

I believe that MGC out of sync with MG is a very bad problem
Audit to determine state at the level of a descriptor in a command is very
hard
Avoiding state change before determining almost all errors is pretty easy
Fixing the few cases where it isn't possible to determine the error is not
very hard.

I'll agree that it is harder to design MG code that does this, compared to
an MG that doesn't
care a whit what the MGC has to do to figure out what state it is in.

I don't think there are any cases where "roll back" doesn't make sense.  You
cited:
    Signals - if the command has an error, I don't want signals specified in
an earlier
        descriptor sent.  I want the whole command to fail
    Events - if the command has an error, I don't want events in a new
events descriptor
        to be detected - I want the old events descriptor to be active

You specifically raised the issue of embedded signals or events.  If the
syntax of the
descriptors is wrong, then that should be detected with the original
command.  Otherwise,
the detection has to be when the first event is detected, and the embedded
event is
activated.  If it fails, the prior signals and events descriptors should be
"restored".  Of course,
I would say they were never changed if there were, for example, insufficient
resources
available for the embedded events following detection of the original event.

I believe that there are many "recoverable" errors.  If there weren't, then
we should make
errors fatal, and specify that contexts are taken down, terminations set to
default state, etc.
Without the MGC knowing the MG state, recovery is very difficult.

Brian

-----Original Message-----
From: Hemant [mailto:[email-masked]]
Sent: Thursday, April 13, 2000 12:18 AM
To: [email-masked]
Subject: Command Atomicity and Rollback

Hi everyone,

    The discussions till date on the issue of rollback of command in case of
its failure do not seem to lead to a clear consensus. Lets look at the issue
from the point of view of both the MG as well as the MGC.

    From an MG point of view, the MG will always have to maintain duplicate
state information. One of the current state (after execution of descriptor)
and another for what existed previous to it while executing the command.
This would be a lot of overhead in terms of memory and implementation
complexity. Also there might cases where rollback doesn't make sense
(signals, event detection etc). Another clarification required is whether
commands with embedded events and signals also be considered atomic? (in
case the embedded signal or event encounters error, what will the MG
rollback to)

     As far as the MGC is concerned, it wants to know the status of the
termination on which command was executed. This can be determined by
Auditing the termination.
    Another MGC concern may be that since the command can fail at any point,
one would think that without rollback implementation, the MGC handling
following a failed command would be very complex. The typical action of the
MGC however in such cases is to follow up with an error treatment(like
playing an error tone or taking the termination out of context or allocating
some other termination etc). Will going back to the previous status really
help the MGC implementation ? If the reason for rollback is to bring the
termination into a state known to the MGC, it can be achieved by auditing
the termination upon receiving the error response.

    Considering the above I would favour that rollback not be mandatory.
Instead on encountering an error, the MG should stop further command
processing.

Any Comments ??

Regards,
Hemant
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hemant Kumar
Ficon Technology
E-mail: mailto:[email-masked] <mailto:[email-masked]>
Web: http://www.ficon-tech.com <http://www.ficon-tech.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 25 Apr 2000 08:01:08 -0400

Maybe the best we can do is an implementor's note saying that the MG should
do things in the way you describe, and should seek to avoid commitments of
state until it has determined that the command can be executed.

> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: Friday, April 14, 2000 3:57 PM
> To:   [email-masked]
> Subject:      Re: Command Atomicity and Rollback
>
> I've had this argument many times before, and always lost it, I think to
> the determent of
> First of all, you can't audit to find out the state of an MG to the level
> of what happened on
>     You should be checking availability of resources either
> simultaneously, or
>         prior to reserving them
>     There are VERY few non-fatal errors that are not detected by the
> above, that
> I don't think there are any cases where "roll back" doesn't make sense.
> You cited:
>     Signals - if the command has an error, I don't want signals specified
> in an earlier
> activated.  If it fails, the prior signals and events descriptors should
> be "restored".  Of course,
> I would say they were never changed if there were, for example,
> insufficient resources
> I believe that there are many "recoverable" errors.  If there weren't,
> then we should make
> errors fatal, and specify that contexts are taken down, terminations set
> to default state, etc.
>           The discussions till date on the issue of rollback of command in
> case of its failure do not seem to lead to a clear consensus. Lets look at
> the issue from the point of view of both the MG as well as the MGC.
>
>           From an MG point of view, the MG will always have to maintain
> duplicate state information. One of the current state (after execution of
> descriptor) and another for what existed previous to it while executing
> the command. This would be a lot of overhead in terms of memory and
> implementation complexity. Also there might cases where rollback doesn't
> make sense (signals, event detection etc). Another clarification required
> is whether commands with embedded events and signals also be considered
> atomic? (in case the embedded signal or event encounters error, what will
> the MG rollback to)
>
>            As far as the MGC is concerned, it wants to know the status of
> the termination on which command was executed. This can be determined by
>           Another MGC concern may be that since the command can fail at
> any point, one would think that without rollback implementation, the MGC
> handling following a failed command would be very complex. The typical
> action of the MGC however in such cases is to follow up with an error
> treatment(like playing an error tone or taking the termination out of
> context or allocating some other termination etc). Will going back to the
> previous status really help the MGC implementation ? If the reason for
> rollback is to bring the termination into a state known to the MGC, it can
> be achieved by auditing the termination upon receiving the error response.
>
>           Considering the above I would favour that rollback not be
> mandatory. Instead on encountering an error, the MG should stop further
> command processing.
>
>       Any Comments ??
>
>       Regards,
>       Hemant
>       E-mail: <mailto:[email-masked]>
>       Web: <http://www.ficon-tech.com>