Issue 4346: Order of processing during Activity completion. (ots-structs-ftf) Source: International Business Machines (Dr. Ian Robinson, ian_robinson@uk.ibm.com) Nature: Uncategorized Issue Severity: Summary: In order to write a portable application or application framework that uses the Activity service, and in order for Activity service implementations to fully interoperate, the ordering and semantics of completion processing need to be more explictly defined than is presently the case. I describe below what is intended and implied by the current specification, but which I believe needs to be more explictly stated to avoid implementations applying different interpretations. 1. Current::complete_with_status(cs) is called 2. This drives ActivityCoordinator::complete_activity(completion_ss_name, cs). This may be a remote call and there is a separate issue as to whether context is propagated on this; it depends on the ActivityPolicyValue of the ActivityCoordinator. 3. The preComplete synchronization signal is distributed. Activity context must be available on the thread when the Actions process this signal. 4. The completion signals are distributed to registered Actions. The presence or not of Activity context with these flows is not defined. I don't think the presence of Activity context hurts and is consistent with the behaviour during synchronization preComplete. OTS is a little different because Synchronization is a TO (OTSPolicy=ADAPTS) whereas Resource is not (OTSPolicy=FORBIDS). One advantage of keeping the context available during completion processing is that the PropertyGroups are available. 5. The childComplete processing occurs in any parent Activity. Logically, the parent coordinator process_signal_set method is called and the SignalSet implementation gets the information it needs from the current Activity (which is the completing activity, still active on the thread) to build the ActivityInformation structure. 6. The context is logically suspended. Any PropertyGroups are called with suspended() and then with completed(). 7. The postComplete synchronization signal is sent. 8. Any remaining Activity service objects for the completing Activity are cleaned up. 9. The call returns to the client. In some respects, it would be better if (5) and (6) could be reversed but this cannot be the case if the child activity context needs to be on the thread for the parent to perform the childComplete processing. Resolution: Change the text so it make things clearer Revised Text: The following text should be added in a section entitled "Normal Activity Completion" within the Implementors view section. In order to write a portable application or application framework that uses the Activity service, and in order for Activity service implementations to fully interoperate, the ordering and semantics of completion processing of an Activity are described in detail in this section. 1. Current::complete_with_status(comp_status) is called 2. This drives ActivityCoordinator::complete_activity(comp_ss_name, comp_status). If this is a remote call then no Activity service is marshalled since the target ActivityCoordinator has an ActivityPolicyValue of INTERNAL. 3. The preComplete synchronization signal is distributed. Activity context must be available on the thread when the Actions process this signal. 4. The completion signals are distributed to registered Actions. Activity context must be available on the thread when the completion signals are distributed. 5. The context is logically suspended. Any PropertyGroups are called with suspended() and then with completed(). 6. The postComplete synchronization signal is sent. 7. Any remaining Activity service objects for the completing Activity are cleaned up. 8. The call returns to the client. Actions taken: June 15, 2001: received issue May 2, 2003: closed issue Discussion: End of Annotations:===== From: ian_robinson@uk.ibm.com Received: from d06mta10.portsmouth.uk.ibm.com (d06mta09_cs0 [9.180.35.6]) by d06relay02.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5FGmaB70718; Fri, 15 Jun 2001 17:48:36 +0100 Received: by d06mta10.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A6C.005C4CA7 ; Fri, 15 Jun 2001 17:48:09 +0100 X-Lotus-FromDomain: IBMGB To: ots-structs-ftf@omg.org cc: issues@omg.org Message-ID: <80256A6C.005C48E9.00@d06mta10.portsmouth.uk.ibm.com> Date: Fri, 15 Jun 2001 17:45:32 +0100 Subject: New Issue: Order of processing during Activity completion. Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: h9fd94[(e9A=7!!%4:!! In order to write a portable application or application framework that uses the Activity service, and in order for Activity service implementations to fully interoperate, the ordering and semantics of completion processing need to be more explictly defined than is presently the case. I describe below what is intended and implied by the current specification, but which I believe needs to be more explictly stated to avoid implementations applying different interpretations. 1. Current::complete_with_status(cs) is called 2. This drives ActivityCoordinator::complete_activity(completion_ss_name, cs). This may be a remote call and there is a separate issue as to whether context is propagated on this; it depends on the ActivityPolicyValue of the ActivityCoordinator. 3. The preComplete synchronization signal is distributed. Activity context must be available on the thread when the Actions process this signal. 4. The completion signals are distributed to registered Actions. The presence or not of Activity context with these flows is not defined. I don't think the presence of Activity context hurts and is consistent with the behaviour during synchronization preComplete. OTS is a little different because Synchronization is a TO (OTSPolicy=ADAPTS) whereas Resource is not (OTSPolicy=FORBIDS). One advantage of keeping the context available during completion processing is that the PropertyGroups are available. 5. The childComplete processing occurs in any parent Activity. Logically, the parent coordinator process_signal_set method is called and the SignalSet implementation gets the information it needs from the current Activity (which is the completing activity, still active on the thread) to build the ActivityInformation structure. 6. The context is logically suspended. Any PropertyGroups are called with suspended() and then with completed(). 7. The postComplete synchronization signal is sent. 8. Any remaining Activity service objects for the completing Activity are cleaned up. 9. The call returns to the client. In some respects, it would be better if (5) and (6) could be reversed but this cannot be the case if the child activity context needs to be on the thread for the parent to perform the childComplete processing. Ian Robinson, Senior Software Engineer, WebSphere Development IBM UK Laboratories, Hursley MP 189 Tel (Ext) +44-1962-818626 (Int) 7-248626 ian_robinson@uk.ibm.com Importance: Normal Subject: Issue 4346: proposal To: ots-structs-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ian Robinson" Date: Thu, 19 Jul 2001 22:25:10 +0100 X-MIMETrack: Serialize by Router on d06ml007/06/M/IBM(Release 5.0.6 |December 14, 2000) at 20/07/2001 08:24:59 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: ]i[!!HVdd9WD`d9g78!! Proposal for resolution of 4346: The following text should be added in a section entitled "Normal Activity Completion" within the Implementors view section. In order to write a portable application or application framework that uses the Activity service, and in order for Activity service implementations to fully interoperate, the ordering and semantics of completion processing of an Activity are described in detail in this section. 1. Current::complete_with_status(comp_status) is called 2. This drives ActivityCoordinator::complete_activity(comp_ss_name, comp_status). If this is a remote call then no Activity service is marshalled since the target ActivityCoordinator has an ActivityPolicyValue of INTERNAL. 3. The preComplete synchronization signal is distributed. Activity context must be available on the thread when the Actions process this signal. 4. The completion signals are distributed to registered Actions. Activity context must be available on the thread when the completion signals are distributed. 5. The context is logically suspended. Any PropertyGroups are called with suspended() and then with completed(). 6. The postComplete synchronization signal is sent. 7. Any remaining Activity service objects for the completing Activity are cleaned up. 8. The call returns to the client. Ian Robinson, Senior Software Engineer, WebSphere Development IBM UK Laboratories, Hursley MP 189 Tel (Ext) +44-1962-818626 (Int) 7-248626 ian_robinson@uk.ibm.com From: "Mark Little" 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). From: "Mark Little" 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 4346: address it later after 4345. [Move to Vote 2, and Ian Robinson to write up.]