OTS — 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.

So, what we're proposing is:

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.

This is covered by issue 4250, close issue