Issue 5452: Failure recovery in Additional Structuring Mechanisms for OTS (ots-structs-ftf)
Source: Red Hat (Dr. Mark Little, mlittle(at)redhat.com)
Nature: 
Severity: 
Summary: The current specification has the necessary hooks for recreating the
distributed activity tree in the event of failures, but the text does not
give an implementers view of what to do. For example, when using
interposition, it is somehow necessary for a SubordinateSignalSet to
remember who (ActivityCoordinator) it was enlisted with so that, upon
failure and recovery, it could enquire as to the status of the activity.
Now, since a SubordinateSignalSet is also a SignalSet, there is a
set_activity_coordinator method that the enroller of the
SubordinateSignalSet could use to pass the reference to it. The
SubordinateSignalSet can then persist this information when (and if) it is
necessary during the protocol. When it recovers, because all IORs are
required to be persistent, it will be able to contact the coordinator and
find out the status.


Some text like the above would be very useful in the spec.

Resolution: 
Revised Text: 
Actions taken:
July 3, 2002: received issue
Discussion: 
Not enough time to discuss in this RTF.
End of Annotations:=====
From: "Mark Little" <mark_little@hp.com> 
To: "XOTS FTF" <ots-structs-ftf@omg.org> 
Cc: <issues@omg.org> 
Subject: Failure recovery in Additional Structuring Mechanisms for OTS 
Date: Wed, 3 Jul 2002 10:14:28 +0100 
X-Mailer: Microsoft Outlook Express 6.00.2600.0000 


The current specification has the necessary hooks for recreating the
distributed activity tree in the event of failures, but the text does
not
give an implementers view of what to do. For example, when using
interposition, it is somehow necessary for a SubordinateSignalSet to
remember who (ActivityCoordinator) it was enlisted with so that, upon
failure and recovery, it could enquire as to the status of the
activity.
Now, since a SubordinateSignalSet is also a SignalSet, there is a
set_activity_coordinator method that the enroller of the
SubordinateSignalSet could use to pass the reference to it. The
SubordinateSignalSet can then persist this information when (and if)
it is
necessary during the protocol. When it recovers, because all IORs are
required to be persistent, it will be able to contact the coordinator
and
find out the status.


Some text like the above would be very useful in the spec.


Mark.


----------------------------------------------
Dr. Mark Little (mark_little@hp.com)
Transactions Architect, HP Arjuna Labs
Phone +44 191 2606216
Fax   +44 191 2606250


From: "Mark Little" <m.c.little@ncl.ac.uk> 
To: <ots-structs-rtf@omg.org> 
Subject: issues 5451 and 5452 
Date: Sun, 6 Apr 2003 20:50:53 +0100 
X-Mailer: Microsoft Outlook Express 6.00.2600.0000 
X-Newcastle-MailScanner: Found to be clean 


Owing to time constraints I'm proposing that we don't vote on either of
these issues this time round, i.e., we leave them open.


Any objections?


Mark.

From: "Mark Little" <m.c.little@ncl.ac.uk> 
To: <ots-structs-rtf@omg.org> 
Subject: Re: issues 5451 and 5452 
Date: Tue, 8 Apr 2003 14:14:11 +0100 
X-Mailer: Microsoft Outlook Express 6.00.2720.3000 
X-Newcastle-MailScanner: Found to be clean 


This was a typo and should have referred to issues 5452 and 5431


Mark.


----- Original Message ----- 
From: "Mark Little" <m.c.little@ncl.ac.uk>
To: <ots-structs-rtf@omg.org>
Sent: Sunday, April 06, 2003 8:50 PM
Subject: issues 5451 and 5452



> Owing to time constraints I'm proposing that we don't vote on either of
> these issues this time round, i.e., we leave them open.
> 
> Any objections?
> 
> Mark.
> 
> 
> 

Issue 5452 (Mark Little)


Leave this issue open.



Mark