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).
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).
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.
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
Thanks - thought-provoking
stuff.
Peter
------------------------------------------------
Peter
Furniss
Choreology Ltd
email:
peter.furniss@choreology.com
phone: +44 20 7670 1679
direct: +44
20 7670 1783
13 Austin Friars, London EC2N 2JX