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


Help: OASIS Mailing Lists Help | MarkMail Help

bt-models message

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

Subject: RE: terminology


Included a sketch that shows possible actors and their communication in a business transaction that I was trying to explain on todays conf call.  
I think we have the addressing (explicit/implicit or both?, and how the service detects that it is in a transaction and how it communicates with its local service manager) and the actors names and their roles shown in the figure. The names that I have used in the figure are just because I need to name them! 
Useful (and colourful :-) diagram. Couple of points (using your terminology)
 The intent of "group" (assuming this is the atomic unit, or whatever) as I had seen it was that it was a unit of decision (i.e. that it there is a single yes/no decision made that is to be applied to elements that have ever been part of the unit.)  Within the "business transaction", it may happen (dependent on results, time etc.) that one or other of the groups is cancelled or withdraws, while the other completes - but within each, all operations go the same way.
The consequence of this is that the server sites don't need to know of the existence of the "business transaction" as a whole (for this purpose) - they only need to know which "group" the operation is part of. In your example this would require SM3 to register with both groups,since it may get different answers (e.g. if S1 says NO, GM1 will be cancelled, but the BT could complete with GM2 alone (if the application/BTM decided that was appropriate)
The situation would be different if you had another operation (S2 ) in G1 that also accessed service S2 (currently unused, and I assume in some fairly close relationship to service S1). In this case the fact that it will be subject to the same atomic decision means that it can be allowed to combine with S1, and share its data (i.e. the second to arrive can rightly use the tentatively final results of the first, subject to the essentially *local* requirement that the two operations don't bury their updates.) SM1 would still only register with GM1 once, and would apply the GM1 decision to both. If S2 were part of G2 however, the second one could not know whether first will commit. (If, instead of S1, you send a second operation to S3, from G2, then the fact that S3 and S3' are in the same group means the two operations can be treated as parts of the same (ACID) transaction - e.g. using xa_start(TMJOIN) to the resource manager))
(the possibility of data sharing is a bit different if SM1, S1, S2 are using a lock-free, local compensation approach to "undo". In that case, the second operation is in exactly the same position as a completely unrelated operation. Since the implementor has assumed that the compensating undo, and any possible operation from anywhere are sufficiently robust that they won't mess each other up, it is presumably safe to let the second operation use the first ones results.

At 01:24 PM 4/10/01 +0100, Mark Little wrote:
Last night we discussed some terminology again, and (amongst the 3 of us who were there) seemed to reach some agreement. I said I'd email the results of the discussion:

(i) there definitely seems to be a need for a terminator actor as well as an initiator. In many cases the initiator and terminator may well be colocated, but that need not be the case (e.g., I begin a BT, but pass control of it to someone else to determine whether it should commit or rollback in my absence).

(ii) the idea of a conductor instead of coordinator was discussed. The conductor term isn't used in this domain as far as we can see, and may help to remove some confusion, especially if people use an ACID transaction system in collaboration with the BTP.

(iii) rather than distinguish between a participant who is a subordinate conductor, we should probably just say that that's an implementation choice for the participant, i.e., as far as the conductor is concerned it sends a prepare message, and what the recipient participant does to come up with the return value is up to it.

I am not sure if the conductor is a good term for this...
(iv) cohesion sounded OK to those involved, though I think Keith was going to see if he could come up with something else.

what about using the term business transaction? I think it is widely accepted that business gradations are not 2PC/ACID transactions...
I'm with those who thinit very unwise to use "transaction" (whatever the qualification) as the name for a precise thing in this. Some listeners will think we mean ACID, some will think we mean colloboration, some will think we mean operation.  (Cohesion - think of the glue on post-it's :-)

(v) atomic group is overloaded terminology too, tending to imply group communication using, say, atomic multicast or virtual synchrony. Atomic unit?
atomic steps, unit of work...?
I'd be happy with atomic unit (though it's possibly tautologous). "unit of work" is LU6.2-speak for 2pc/ACID transaction.

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