[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: terminology
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.
(iv) cohesion sounded OK to those involved, though I think Keith was going
to see if he could come up with something else.
(v) atomic group is overloaded terminology too, tending to imply group
communication using, say, atomic multicast or virtual synchrony. Atomic
unit?
Mark.
----------------------------------------------
Dr. Mark Little (mark@arjuna.com) Transactions Architect, HP Arjuna Labs Phone +44 191 2064538 Fax +44 191 2064203 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC