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.
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. 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,
I'm fairly sure the
operations have to be identified as to which group they are part of, so in
that sense the structure of the group is visible. (they may carry other
identification, but at least the group)
Given
that, whether the data is shared is essentially decided by the holder
of the data (the participant side). Because the participant knows the
operations in the group will all get the same decision it is inherently safe
to share– multiple operations that will all-or-none confirm can build on
each others results, subject to
the (local) constraint that they are implemented such that they do
not risk buried updates. (this is essentially tight- or loose-coupling as
described rather approximately in XA).
Are you assuming all group members
are on the same machine/domain?
Alternatively, the holder of the data
could keep its promise to make the operation group reversible by keeping a
separate compensation operation for each individual operation, and not
applying any isolation – in that case subsequent operations in the group
will have exactly the same access as unrelated operations, and imply the
same threats to invalidating the compensation. I’m not sure it’s helpful to
call this “sharing data”, since it is distinctly different from the
privileged access that can be allowed to operations that are known to be
subject to the same decision, if the holder of the data wishes
to.
(2) the operations are
long-running or short duration,
In general, could be either. Obviously they are no longer than
duration of the action as a whole. If an operation is communicated as a
message exchange over SMTP (say), there’s no reason why it might not take
days, but still be a single operation (consider a price query, detailed
tender sequence) . Conversely, there are some scenarios (network control, banking)
that need these mechanisms in general but still count time in
seconds.
(3) the reversibility with
one operation the criteria for grouping or there are other
criterias
A group is characterised by a single decision to be applied to
all parts. It may (subject of issue in 4-levels document) involve more than
one participant (at different places). At some point (perhaps in the API,
that's a single operation, and I’d assumed there would be only one message
to cancel the group sent to each participant involved in it, but that could
getting into too much detail. (This relates to some actor, identification, terminology
issues that will get resolved - especially what's a "participant"
exactly)
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. 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) 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).
lost you there :-(
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?
If
you know (or suspect) that two operations will need to be processed by the
participant in the same context (i.e. to share data), then you need to
signal this to the participant side by putting them in the same group. If
you know you will (or might) confirm one operation and cancel another, you
must put them in separate groups within one action. If neither criteria
apply, you can do either, as you say. If both criteria apply, you
may be into the realm of nesting (and lock-inheritance) - or they could be
separate groups and let the participant side sort it out if it
can.
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.
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.
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.
yes, exceot I'm not clear on "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.
Yes - we'ed go for an explicit vote though -
"results" could mean the application-mediated answer.
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.)
Yes - we had
perceived the compensation operation as being delegated to the
participant side, triggered on receipt of a (BTP) cancel message. This then
makes compensation a particular way of doing rollback (or database-style
rollback a particular way of doing compensation, with the virtue of no
collateral damage).
So you're
assuming a model whereby failure has to cause some kind of compensation? Or can
we leave that to the application, i.e., a failure generates a "failure" message,
and how that is interpreted at the group/participant level is up to the model
(or participant). Interestingly, strictly speaking I can do something similar in
a transaction system: a participant receives a rollback message from the TM and
I would hope it does something to undo the work that was done within the scope
of the transaction to guarantee ACID properties. However, it doesn't actually
need to, i.e., I could build an "extended" transaction model on top of a
traditional transaction system by overloading what it means to get a
commit/rollback message.
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
The applications responsibility, surely
?
2) only allow reversible
operations
This is effectively assumed in what we've said, I
think. If a business process must involve non-reversible operations, then it
must, and it will have to handle the inappropriate performance of them in
some way. But that doesn't seem tractable to protocolising, in the sense of
an inter-party, inter-system protocol. Coping with the irreversible may
involve "compensation" in a general sense, but there will normally be
nothing to communicate that directly links the original and balancing
operations.
Just because an operation is compensatable
doesn't mean that it should be compensated. It may depend upon factors at
runtime. By the time a failure occurs, it may be entirely inappropriate to
compensate. Check out the share purchase/selling example in the HP proposal for
example.
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).
That's probably best considered an implementation
detail- in some cases it may be easier for the recipient of a set of
operations in one group to have a single compensation for the group
(probably essential if data-sharing had taken place) - which (with the
mapping of names) is what happens if the operations have in fact been
performed as one transaction in an XA database
Mark.
----------------------------------------------
Dr. Mark Little ()
Transactions Architect, HP
Arjuna Labs
Phone +44 191 2064538
Fax +44 191 2064203
