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?



 
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.
Yes, missed that.
 
 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:
 
 

 

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)

However, this doesn't address the issue of all inferiors resigning or cancelling for prepare_inferiors. In a traditional transaction system (and presumably for atoms), if I issue a prepare and get back cancel/readonly from all participants, I don't have to send anything else to that transaction because I know it has finished. With cohesions, as I mentioned earlier, the situation is different. In some cases I'd like implementations to be able to free up resources held by the coordinator implementation immediately simply because there won't be any other registrations *and* the application shouldn't have to explicitly terminate such a cohesion which now has no members.
 
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