OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: New Issue - Race condition before correlation set is established


Title: New Issue - Race condition before correlation set is established

Document: 1.1 Spec (Sample on p.22)
Description: Current specification does not address implementation semantics for registering correlations

Handling Callbacks in a Business Process (especially if it is done like suggested in the Initial Example of the 1.1 Spec) is depending on unspecified runtime engine behavior.

If we assume, that a new entry for a correlation set is entered on activation of the receive, and we also assume, that incoming web service requests on ports which have no matching correlation are rejected, we have a small window in the system, where a particular information was requested, but the related receive activity was not yet activated. This could be, because the requested party will answer, before the SOAP communication was finished, it could also be, because the runtime engine is loaded, to not enable the receive fast enough. It could also be because the runtime engine was putting the process to sleep because or priority issues.

The specification should either enforce a semantic which will allow <sequence><invoke><receive></sequence> process, and force implementers to keep that case in mind, or the specification should endorse (and then actually use in its own samples) an alternative way.

Please keep in mind, that it might not be enough to assure, that implementations can handle the response to an invoke of the directly following activity. Flows and sub process could be involved, too. In the case of flows, the current spec does not assume any implementations, which is good for implementing conforming engines, but it is also bad for specific modeling techniques which may be unsafe to use. A good sample would be a <flow><receive /><invoke /></flow> which also has the same (maybe even bigger) race condition window to allow callbacks.

A process which creates a correlation id, waits for the response and then invokes the service is a typical use case. Issue 31 is a feature request which would depend on this, and will suffers from the same unspecified behavior.

Alternative solution (which is a bit overhead, unfortunately): allow a new link type "ready to receive" from receive components to invoke components, which will be enabled, as soon as the corresponding correlation entry is made, and the system is listening for the callback. Brainstorming welcome.

Links: Issue 31



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]