OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Some comments on definition of operation/group and action

I've responded where I'm fairly sure and am still thinking on other bits.
Sazi Temel sent:
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 
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 Furniss
Choreology Ltd

email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
13 Austin Friars, London EC2N 2JX

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC