[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 36 - Proposal to vote - Multiple instances of event handler
On Point#1 I have the same
interpretation. On Point#2 I don’t see the problem. We are not
specifying any buffer mechanism for these message delivery semantics. All we
can say is that each message is assigned to a new instance of the handler and
each instance of the handler has its own private variable for holding the
message. Implementations can worry about making sure there is no race at the
message buffers if they have any. From: Prasad Yendluri [mailto:pyendluri@webmethods.com] I guess only when one tries put things in black and
white himself, one sees these... 6. Upon receipt of the input message the event handler
assigns the input Isn't there a timing issue here
still? This is almost similar to the original issue, in that
Proposal to resolve issue 36.
The semantics of event handler would be changed to allow the variable used to capture the input message to be treated local to the event handler instance:
1. Rename eventHandler/onMessage to eventHandler/onEvent
2. The name of the variable is given in the variable attribute.
3. The attribute messageType specifies the variable type by referencing the message type definition using its QName.
4. The variable type must be the same as the type of the input message defined by referenced operation.
5. The event handler declares a variable of that name and type that is scoped to the event handler activity.
6. Upon receipt of the input message the event handler assigns the input message to the variable before proceeding to perform the event handler activity.
7. Since the variable is scoped to that activity, two instances of the activity (whether executed seriallly or concurrently) do not operate on the same variable.
arkin
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]