Issue 4304: interposition (ots-structs-ftf) Source: University of Newcastle upon Tyne (Dr. Mark Little, m.c.little@ncl.ac.uk) Nature: Uncategorized Issue Severity: Summary: There has been a bit of discussion about the problems with implementing efficient interposition using global actions. The notion of global actions came about because it was originally thought that a downstream node would not need to have access to the same SignalSets that an upstream node had. However, although global actions make this possible, they make implementing efficient interposition very difficult. It also turns out that it makes more sense to require downstream nodes to have the same knowledge of the activity SignalSets as upstream. So, what we're proposing is: (i) whenever an Action is registered with a SignalSet at a downstream node (A), that node must register a SubordinateSignalSet (see below) with the parent node (B). This need only be done once per SignalSet. It means that a downstream node is only informed about Signals that mean anything in it's context. Obviously B may be a downstream node to, say, Z, and as a result of having A register with it may then need to register an Action with A. (ii) add a SubordinateSignalSet that derives from SignalSet and add the single method set_signal, which takes a Signal. A SignalSet is a finite-statemachine, and usually starts from point 0. set_signal lets it start (or re-start) from any point in the FSM. Whenever an interposed coordinator receives a Signal it passes it to the interposed signalset for that Signal using set_signal, and then uses the SignalSet as it would normally, i.e., calls get_signal, set_response etc. The interposed SignalSet can then collate the responses and send a single Outcome back. However, it can also do the local optimisations mentioned in an earlier email. So, for example, if a local Action responds with an outcome that can only mean the activity will rollback, rather than send that response back to B, A could do the local rollback on all registered participants first, saving B the time to send the next message. Resolution: This is covered by issue 4250, close issue Revised Text: Actions taken: May 13, 2001: received issue May 2, 2003: closed issue Discussion: End of Annotations:===== From: "Mark Little" To: "XOTS FTF" Cc: Subject: interposition Date: Mon, 14 May 2001 13:32:02 +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_0057_01C0DC7A.4244CD60" X-UIDL: Ib"!!8*He98OSd9 cc: ots-structs-ftf@omg.org Message-ID: <80256A4F.004B0600.00@d06mta05.portsmouth.uk.ibm.com> Date: Thu, 17 May 2001 14:19:30 +0100 Subject: Re: Issue # 4304 - interposition Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: C#Je9mfZd91J8e9VXC!! Mark - you wrote: "Whenever an interposed coordinator receives a Signal it passes it to the interposed signalset for that Signal using set_signal, and then uses the SignalSet as it would normally, i.e., calls get_signal, set_response etc. The interposed SignalSet can then collate the responses and send a single Outcome back" In order to preserve the existing semantics of get_outcome returning the 'final' outcome of the SignalSet, we need a get_current_outcome() on the interposed SignalSet in order to determine the outcome for a received signal, once it has been processed. 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 "Mark Little" on 14/05/2001 13:32:02 Please respond to "Mark Little" To: "XOTS FTF" cc: issues@omg.org Subject: interposition There has been a bit of discussion about the problems with implementing efficient interposition using global actions. The notion of global actions came about because it was originally thought that a downstream node would not need to have access to the same SignalSets that an upstream node had. However, although global actions make this possible, they make implementing efficient interposition very difficult. It also turns out that it makes more sense to require downstream nodes to have the same knowledge of the activity SignalSets as upstream. From: "Mark Little" To: Cc: References: <80256A4F.004B0600.00@d06mta05.portsmouth.uk.ibm.com> Subject: Re: Issue # 4304 - interposition Date: Mon, 21 May 2001 12:04:00 +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: 8N'!!RG/e9i-#e9G\!"! > "Whenever an interposed coordinator receives a Signal it passes it to the > interposed signalset for that Signal using set_signal, and then uses the > SignalSet as it would normally, i.e., calls get_signal, set_response etc. > The interposed SignalSet can then collate the responses and send a single > Outcome back" > > In order to preserve the existing semantics of get_outcome returning the > 'final' outcome of the SignalSet, we need a get_current_outcome() on the > interposed SignalSet in order to determine the outcome for a received > signal, once it has been processed. Agreed. Mark. ---------------------------------------------- Dr. Mark Little (mark@arjuna.com) Transactions Architect, HP Arjuna Labs Phone +44 191 2064538 Fax +44 191 2064203 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 4304: addressed in 4250. [Vote to close, but Mark Little to write up.] From: "Mark Little" To: "XOTS FTF" Subject: Proposal for 4304 Date: Tue, 31 Jul 2001 16:36:32 +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: eFAe9%SF!!?\8e9FdV!! I would like to close this issue in light of the 4250 issue. 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