Sazi,
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.
--Sazi
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 think it 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
------------------------------------------------
Peter
Furniss
Choreology Ltd
email:
phone: +44 20 7670 1679
direct: +44
20 7670 1783
13 Austin Friars, London EC2N 2JX
