RE: terminology

From
Pal Takacsi-Nagy <>
Date
2001-04-12T05:57:17+00:00
ID
Thread
RE: terminology
Mark,

 

I 
don't really like the word conductor, it reminds me trains not transactions. I 
don't think coordinator is overloaded.

Cohesion sounds fine, although a little too academic. 
How about "Web transactions" or "Light-weight transactions"?

 

Anyway, I think there is convergence on the terminology 
and requirements. 4/30 is approaching, so do you think that you guys (the bt 
models group) can start to put together a draft requirements/use 
cases/terminology document that we can discuss at the 4/23 
f2f?

 

Thanks: Pal

  
-----Original Message-----
From: Mark Little 
  [mailto:]
Sent: Tuesday, April 10, 2001 5:25 
  AM
To: bt models
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 ()
Transactions Architect, 
  HP Arjuna Labs
Phone +44 191 2064538
Fax   +44 191 
  2064203