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: Re: [wsbpel] Issue 245 - Proposal for Vote


+1

Assaf

On 3/7/06, Mark Ford <mark.ford@active-endpoints.com> wrote:

The current specification does not address how to handle concurrency within an onAlarm with a repeatEvery expression. I outlined a few choices which assumed that concurrency would not be allowed but I am in favor of Danny's suggestion which was to simply drop the text that stated onAlarms could not have simultaneous active instances.

I have exchanged a few emails with Alex and I believe that he has crafted a simple change to the existing text in Section 12.5.7 which solves the problem

 
---- Begin existing text ----

12.5.7. Concurrency Considerations

Multiple onEvent and onAlarm events can occur concurrently and they are treated as concurrent activities even if they are request/response events representing the same partner link, port type, operation and correlation sets. The constraint that there can be at most one outstanding synchronous request on a given partner link at a given port type and operation applies here as well (see Providing Web Service Operations). Concurrent invocation of event handlers necessarily relies heavily on the use of isolated scoping to ensure consistent access to shared variables.

Note that, unlike onAlarm event handlers, individual onEvent event handlers are permitted to have several simultaneously active instances.  A private copy of all process data and control behavior defined within an event handler is provided to each instance of an event handler.  This includes the behavior of links defined within an event handler.  Each instance of the event handler must independently evaluate the status of the link as needed.

---- End existing text ----

Changes required:

#1 First paragraph, last sentence changes to:

Concurrent invocation of event handlers, including both <onEvent> and <onAlarm> with a repeatEvery expression,  necessarily relies heavily on the use of isolated scoping to ensure consistent access to shared variables.

#2 Replace second paragraph with the following text:

A private copy of data and resources (including partnerLinks and control links) declared in the associated scope is provided to each instance of an event handler.

---- Begin proposed text ----

12.5.7. Concurrency Considerations

Multiple onEvent and onAlarm events can occur concurrently and they are treated as concurrent activities even if they are request/response events representing the same partner link, port type, operation and correlation sets. The constraint that there can be at most one outstanding synchronous request on a given partner link at a given port type and operation applies here as well (see Providing Web Service Operations). Concurrent invocation of event handlers, including both <onEvent> and <onAlarm> with a repeatEvery expression,  necessarily relies heavily on the use of isolated scoping to ensure consistent access to shared variables.

A private copy of data and resources (including partnerLinks and control links) declared in the associated scope is provided to each instance of an event handler.

--- End proposed text ---




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