RE: [bt-spec] When to garbage collect cohesions?

[Peter Furniss <peter.furniss@choreology.com>]

cancel_transaction will terminate the cohesion - this was considerably why we split apart cancel_inferiors and cancel_transaction (previously cancel/inferiors and cancel/whole) in the solution of issue 79. This is stated tersely in the abstract message descriptions (after the parameter lists, with a note about cancel_inferiors/all ), and better explained in the model section that covers evolution of the confirm-set, for which my skeleton is:

 

 

terminator may issue PREPARE_INFERIORS for some subset of the Inferiors  *but only to a composer*

 

terminator may issue REQUEST_INFERIOR_STATUSES - regardless of type

 

terminator may issue CANCEL_INFERIORS for some subset *but only to a composer*

 

those can be issued repeatedly, in any order.

 

eventually, terminator issues one of

 

CANCEL_TRANSACTION - cancels all inferiors and ends the transaction

 

CONFIRM_TRANSACTION

   if this is a cohesion composer, the inferiors-list parameter may be present, and the confirm-set is only the inferiors in it

   if the inferiors list is absent (which it must be for an atom coordinator, and can be for a cohesion composer) the confirm-set is all un-resigned inferiors.

 

If RESIGN has been or is received from an inferior, that inferior is immediately removed from the set of inferiors, and from the confirm-set (if it was in it)

 

CANCEL is sent to all inferiors not in the confirm-set (only applies for cohesions)

 

if for any inferiors in the confirm-set, neither PREPARED or CANCELLED has been received and PREPARE has not been sent to it, PREPARE is now sent

 

if (eventually) for all inferiors in the confirm-set set, PREPARED has been received, the list of inferiors is persisted. if this works, CONFIRM is sent to the inferiors of the confirm-set.

 

If CANCELLED is received from any infeiror in the confirm-set, all the confirm-set is cancelled.

 

which looks like it's going to come out as a state diagram (and perhaps needs a little tweaking to cover spontaneous PREPARED, CANCELLED, RESIGN in the "active" phase)

 

Peter

 

-----Original Message-----
From: Mark Little [mailto:mark_little@hp.com]
Sent: 20 February 2002 10:22
To: Peter Furniss; BT - spec
Subject: [bt-spec] When to garbage collect cohesions?

Given that we allow prepare_inferiors and cancel_inferiors to be called many times during the lifetime of a cohesion, this raises an interesting garbage collection problem: when is a cohesion finished? If I send confirm_transaction then the answer is easy. However, consider the case where prepare_inferiors(all) indicates they all cancelled or resigned, or cancel_inferiors(all) says likewise, is the cohesion finished? The answer is "perhaps", or "it depends", since surely I may expect new inferiors to be enlistable later? But maybe I don't! Perhaps I do want the cohesion to terminate?

 

Solution? Several:

 

(i) we mandate that every user of a cohesion must send confirm_transaction. Not my favourite option.

 

(ii) if prepare_inferiors(all) or cancel_inferiors(all) is used and they indicate all current inferiors have gone away, then the cohesion is finished. Again, not a great idea but it does cut down on an explicit "end cohesion" message.

 

(iii) add an explicit "end cohesion" message. Hmmm, see above.

 

(iv) we add a Qualifier that basically says do (ii) if the conditions are right. The default is don't.

 

Or maybe I've completely missed something in the spec that already covers this.

 

Mark.

 

----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax  : +44 191 2606250