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 ---