Re: [wsbpel] Issue 36 - Proposal to vote - Multiple instances ofevent handler

[Assaf Arkin <arkin@intalio.com>]

Prasad Yendluri wrote:

> I guess only when one tries put things in black and white himself, one 
> sees these...
>
> I need to seek some clarifications on the resolution..
>
> 1. The resolution does not talk about partnerLink, portType and 
> operation attributes that
>     currently exist on <onMessage/> event handler. I take that is 
> because <onEvent> added
>     the messageType attribute but did not take away the other 
> attributes. This is perhaps obvious
>     but I better seek a clarification prior to modifying the spec.

The resolution only includes a list of changes to what is currently in 
the spec. Everything else stays as it was. So there's a change to the 
element name, and a new attribute added, but it doesn't take away 
existing attributes.


> 2.  Item 6 in the resolution says,
>
>     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.
>
>     Isn't there a timing issue here still? This is almost similar to 
> the original issue, in that
>     what if another message comes through prior to the eventHandler 
> actually having a
>     chance to copy out the value to the local variable?

Order of processing is, a) get the message, b) assign it to variable, c) 
perform activity. The behavior is very precise in the sense that things 
occur in certain order, doesn't mean it has to be pre-emptive and allow 
other things to occur inbetween. Also, the continuity does imply that a 
race condition is not possible (how you resolve it is a technical 
issue), since each time you do a) you have to follow it with b) and c).

arkin

>
> Thanks for the clarifications.
>
> Prasad
>
> -------- Original Message --------
> Subject: 	[wsbpel] Issue 36 - Proposal to vote - Multiple instances of 
> event handler
> Date: 	Fri, 10 Oct 2003 18:47:16 -0700
> From: 	Assaf Arkin <arkin@intalio.com>
> To: 	wsbpel@lists.oasis-open.org
>
>
>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
>
>  
>


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.