You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by "THOMAS, JAYANT (SBCSI)" <jt...@att.com> on 2006/09/01 02:16:36 UTC

RE: Shale + SCXML integration:

So we are not parsing the sxcml per request, the current implementation
in the usecase looks like it is parsing the document per session and
storing the scxml executor in the session.
Thanks
Jayant

-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com] 
Sent: Wednesday, August 30, 2006 2:13 PM
To: Jakarta Commons Users List
Subject: Re: Shale + SCXML integration:


On 8/30/06, Craig McClanahan <cr...@apache.org> wrote:
<snip/>
>
> If we use an executor per active instance of a dialog (i.e. per
ScxmlContext
> in the sandbox API), then we don't have to worry about anything -- a
JSF
> view can only be accessed by one thread at a time, so we should be OK.
The
> only time we'd have to worry about it is if shared a single executor
for an
> entire user, in session scope.
>
<snap/>

Thats great, thats what the dialog2 patch from earlier today does.
OTOH, the usecases example on the Commons SCXML website follows the
legacy dialog API, so warrants a note to that effect.

All state machine abstractions will have a critical region, wonder how
other "dialog" technologies have solved this.

-Rahul


>
> Craig
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org