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

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

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


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


 
 
PF: yes, the "tweaking" needs to include the automatic completion of an atom in case of cancel and some other stuff. With a cohesion, I think this comes down to wanting to delegate a completion rule down to the coordinator implementation. It's already possible for the terminator to do this in one case - if it knows what the confirm-set would be, even if some of the inferiors in it haven't prepared yet (e.g. if this cohesion is to confirm, it must include exactly inferiors A, D and E as confirming or readonly) it can issue CONFIRM_TRANSACTION, which will run the prepare phase where needed. In the case you're positing, the terminator can't yet say that, so presumably it would find some combinations of prepared inferiors acceptable, but there must be at least one un-cancelled inferior. But that looks rather like just a particulat case - for some cohesions it might be at least two, for others one particular inferior is essential, for others various complex combinations. I doubt if it's worth complicating things for the automated resource freeing in what must be a fairly unusual case (a self-emptying cohesion must surely be a bit unusual for any application)
Actually the situation I'm considering is more specific than this: the driver of the cohesion knows that the lifetime of the cohesion as far as enrolling participants is concerned is about to end when it starts a specific prepare_inferiors, i.e., no more inferiors will be enrolled (or at least by any of its own actions). If prepare_inferiors says everything prepared then it will either decide to confirm or cancel them later. (It does not know which way it will jump until after issuing prepare, so it can't call confirm_transaction or cancel_transaction). So, if all of the inferiors say they have cancelled the coordinator factory/manager implementation should be able to release those resources since a cancel_transaction is superflous. Likewise, if they all say resigned.
 
Mark.
 
----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax  : +44 191 2606250
 
 


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


Powered by eList eXpress LLC