From the requirements #1, #2 and #3, one may derive the definitions of
key terms. An action(A), also called Business Transaction is a collection of
group of operations where a group has a single reverse operation(<-R) that
can back out the effect of all the operations(o) executed in the group(G). The
group operations has the atomic effect; group of operations always complete,
either success or failure -failure requires back out, no forward recovery.
If a group spans multiple different domains/vendors then it may be
impossible to guarantee that a group is atomic (unless we supported nested
transactions). For example, each operation within a group may actually be a
separate top-level ACID transaction, and if we commit the first 2 undoing them
may not be possible if the third operation fails. If we require nested
transactions to encompass a group then we can say that the group will be atomic.
Something we need to consider tomorrow.
It looks like the group is the unit of work that takes a business
(trans)action from one stable state to the other, on success or business
(trans)action stays in the previous (or initial) stable state, on failure. It
only concerns with backward recovery, there is no forward recovery in the
group -like an ACID transaction.
I have no problem with this definition given the above proviso.
Although, it is implicit that the operations in the group might be ACID
transactions and/or other business calculations, it is not clear whether
(1) the operations share data and the structure of the group is visible to
operations in and out of group,
(2) the operations are long-running or
short duration,
(3) the reversibility with one operation the criteria for
grouping or there are other criterias
Isn't this up to the application/extended transaction model being
used?
Action including a reverse operation and group of operations where
operations may also be ACID transactions(t) and/or other business computations
creates a two level nested structure shown in example below:
A
{G1[(o1,t1,o2)<-R1], G2[(t1,t2,o1,o2)<-R2], G3[(t1)<-R3]}
In
which, in case there are multiple ACID transactions in the group the structure
of group will be exposed(at least partially) to the other transactions (once
they are committed) unless the group represents a nested transaction or a
similar transaction model where the transactions in the group are siblings in
the transaction tree and locks are hold by the parent.
If we used nesting then the different members of the group may see the
outcomes of each other if the commit. We also need to determine whether group
members are executed sequentially or in parallel.
Thus exposing the structure of the group, on one hand, may create a
situation where backward recovery might not be possible (as suggested
per group definition)
As we tried to show in the HP submission, unless you have strict ACID
transactions backward recovery can not be guaranteed. If you come up with some
scheme where backward recovery is guaranteed in a finite amount of time then I'd
be interested to see how it compares to traditional ACID-ity. You don't get
something for nothing, and what we should be looking at is how to trade off
things like consistency and isolation of performance.
and on the other hand, introducing forward recovery into the group makes
it more like (trans)action which might allowed forward recovery thru
compensation and contingency (as I understood from the submission).
What are the differences between action and group and, group and
operation? When the definition of the terms are not clear creating group of
operation or action become users and developers choice. From the examples
given, I can design a business transaction as a single group of operations in
an action; A {G1(o1,o2,t1)}<-R1} or I can design it as 2 or 3 groups of
operations in an action; A {G1[(o1)<-R1], G2[(o2)<-R2], G3[(t1)<-R3}.
Both solutions (and possible more others) are valid, but which one is less
error prone? We need clear criteries for qualifying what an operation is, what
a group is and what an action is. Need to come with a more precise
definitions that will exclude many of the random combinations of composing
actions and group of operations.
Agreed, and we need to make the model simple. The *big* advantage of
traditional transactions is the simple model: people can understand what it does
and don't have to worry about what's going on under the covers. Typically all
they have to do is scope a transaction and let the TM do the work. A simple
model or models should be a goal.
Designing a better business transaction is very vital since a bad
transaction design will definitely yield cascading backward recovery, this is
so with ACID transactions too (a bad transaction design may yield rollback,
but no consistency problems occur normally) but it is more critical with
business transactions since we have to deal with restoring the consistency
thru compensations and perhaps compensations of compensations etc., it is more
problematic.
Are you assuming that compensations are the way to go for all business
transactions? I don't think they are, and in only a small set of well-behaved
scenarios can they be provided for automatically by the transaction
infrastructure. Most compensations will have to be provided by the application,
and then why make them distinguished entities? Personally I don't think we
should make a distinction: if a group (or activity in the HP proposal) fails
then that may cause another activity to execute that just happens to compensate
for the failure. Also, compensations may not be required at all. We tried to
illustrate some of the issues with compensations that tend to get overlooked:
what if a compensation fails? what if we cannot guarantee that a compensation
can succeed, even if failures don't happen?
One may define an operation as any kind of business computation with the
following characteristics:
1) It is registered with group, i.e the group is
aware of it. Note that a group may have many other operations but not visible
to the group.
2) Its results (only success or failure - like a vote, yes or
no) will be accessible so that a group decision can be made.
3) It has a
reverse operation, i.e a compensation that it registered with group so that in
case of backward recovery it may be applied. (The compensation/reverse-op may
be no-op.)
One may also try to eliminate some of the inconsistencies
that might be created during group operations. This may require semantic
analysis of the group operations. For example we may define the operations so
that
1) they will not perform operations that may create
inconsistencies
2) only allow reversible operations
Also, a single
operation to reverse the group of operations (as suggested in the Choreology
submission) may be complicated especially if there are several operations in
the group since the reverse operations should have enough information on the
failure case to execute a correct version of the recovery. Each operation
having its own compensation might be an alternative (and a master compensation
that will execute the others).
Cheers,
Mark.
---------------------------------------------- Dr. Mark Little ( mark@arjuna.com) Transactions Architect, HP
Arjuna Labs Phone +44 191 2064538 Fax +44 191 2064203
|