Issue 5431: asynchronous responses
Issue 5452: Failure recovery in Additional Structuring Mechanisms for OTS
Issue 5934: Forcing child activities of completed parents to fail is too restrictive
Issue 8954: formal/05-01-01 - Additional Structuring for OTS - incorrect figures
Issue 5431: asynchronous responses (ots-structs-ftf)
Click here for this issue's archive.
Source: Red Hat (Dr. Mark Little, mlittle(at)redhat.com)
Nature: Uncategorized Issue
Severity:
Summary:
Currently the core of the Additional Structuring Mechanisms for the OTS (aka Activity Service) assumes synchronous responses from participants (Actions) at the instigation of the coordinator messages (generated by the SignalSet). As we have found in several recent studies and other work on extended transactions (e.g., the OASIS BTP) there are good reasons why participants may want to asynchronously send "responses" to messages the coordinator hasn't yet generated. For example, in a two-phase protocol, a participant may be able to spontaneously prepare and send the coordinator the relevant Outcome. In the current spec. this isn't possible directly. Obviously there are tricks that could be played with another-level-of-indirection (e.g., enlist a "cacheing" participant with the coordinator that the real Action enlists with and this receives [and stores] any spontaneous responses). However, even this doesn't really address the entire problem since the response the Action sent (the Outcome) is made with respect to a presumed specific Signal that the coordinator sent. So, what if the coordinator doesn't send that Signal? Having this as part of the core will help us to continue to support a wide range of coordination/extended transaction protocols.
Not enough time to discuss in this RTF ..deferred
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.
Not enough time to discuss in this RTF.
Section 2.2.9 of the specification, in the description of the compete method, includes the following text: "If the completion status is CompletionStatusFail, or CompletionStatusFailOnly, any encompassed active or suspended Activities will then have their completion status set to CompletionStatusFailOnly and transactions will be marked rollback_only." This behaviour is too restrictive for extended transaction models that may wish to allow child activities to complete successfully despite the fact that a parent activity is failed. I suggest that this restriction be removed.
the activity depicted in figure 1.2 does exhibit a failure whereas the figure depicted in figure 1.3 does not exhibit a failure the titles of these figures are correct but the contents should be interchanged