Issue 4301: failure assumption (ots-structs-ftf) Source: University of Newcastle upon Tyne (Dr. Mark Little, m.c.little@ncl.ac.uk) Nature: Uncategorized Issue Severity: Summary: The current draft of the Activity Service implicitly assumes a "presumed abort" type protocol, but doesn't mention it explicitly. The only reference an Action has to the activity it is involved with is the ActivityCoordinator it registered with. Now, if that coordinator is defunct (e.g., it failed before termination or simply decided to "abort" and couldn't get through to the Action because it had failed) when the Action calls get_status it will presumably get an OBJECT_NOT_EXIST exception. The Action should use this as an indication of a roll back, and act accordingly. Resolution: Add a Failure Assumptions subsection in the Implementor's View Revised Text: Many commercial transaction systems use a presumed abort protocol to simply the requirements on failure recovery: if a participant enquires as to the status of a transaction and the system definitely has no record about the transaction, then it is assumed to have aborted (rolled back), and the participant can act accordingly. This means that a transaction coordinator need not keep persistent records of participants until after it has decided to commit. Therefore, Activity Service implementations are also required to use a presumed abort protocol. The Activity Service also assumed that IORs for participants (Actions) and coordinators are persistent, such that upon recovery from failure, an end-point for an IOR remains valid as long as the object it refers to remains in existance. Therefore, a client receiving an OBJECT_NOT_EXIST exception can be guaranteed that the object has ceased to exist because it has successfully completed its job. Actions taken: May 14, 2001: received issue May 2, 2003: closed issue Discussion: End of Annotations:===== From: "Mark Little" To: "XOTS FTF" Cc: Subject: failure assumption Date: Mon, 14 May 2001 13:14:49 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01C0DC77.DABC0CF0" X-UIDL: P`>!!](:!!mh5!! To: "XOTS" Subject: FTF meeting summary Date: Wed, 18 Jul 2001 10:05:44 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Filter-Version: 2.1 (cheviot3) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: *%D!!CL[d9H0jd9D]:!! Just a quick note to report on the meeting we had at Danvers. We managed to work through all of the issues that were reported prior to Danvers, though some have come up since. A brief summary of the issues we discussed, and the resolutions follows (the individuals who will write up the final proposed resolutions are also indicated). Proposal for 4301: clarify text to presumed-failure. Also clarify that all IORs are persistent, and OBJECT_NOT_EXIST really does mean that! [Mark Little to write up.] From: "Mark Little" To: "XOTS FTF" Subject: Proposal for 4301 Date: Tue, 31 Jul 2001 16:30:06 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: FH!e9-&+!!$_7!!BX;e9 Add a Failure Assumptions subsection in the Implementor's View which says: Many commercial transaction systems use a presumed abort protocol to simply the requirements on failure recovery: if a participant enquires as to the status of a transaction and the system definitely has no record about the transaction, then it is assumed to have aborted (rolled back), and the participant can act accordingly. This means that a transaction coordinator need not keep persistent records of participants until after it has decided to commit. Therefore, Activity Service implementations are also required to use a presumed abort protocol. The Activity Service also assumed that IORs for participants (Actions) and coordinators are persistent, such that upon recovery from failure, an end-point for an IOR remains valid as long as the object it refers to remains in existance. Therefore, a client receiving an OBJECT_NOT_EXIST exception can be guaranteed that the object has ceased to exist because it has successfully completed its job. Mark. ---------------------------------------------- Dr. Mark Little Transactions Architect, HP Arjuna Labs Email: mark@arjuna.com | mark_little@hp.com Phone: +44 191 2064538 Fax : +44 191 2064203