commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "THOMAS, JAYANT \(SBCSI\)" <jt8...@att.com>
Subject RE: Shale + SCXML integration:
Date Wed, 30 Aug 2006 01:40:03 GMT
Thanks, As you can see SCXMLDialogNavigationHandler  is a singleton and
handleNavigation will be accessed by the many users concurrently. if we
use servlet context to store the   SCXMLExecutor, we have single
instance for all the users so the implementation itself will have
issues, so which ever framework we use the scxml executor will have
issues unless we create a new instance for each request or model the
SCXMLExecutor itself as a controller , also iam not sure why the
SCXMLExecutor is not thread safe ??., we cannot use synchronize blocks
in a servlet request since it will block all the request.

It will be nice if we can implement the SCXMLExcector as part of the
Shale framework itself.
Thanks
Jayant 
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com] 
Sent: Tuesday, August 29, 2006 6:51 AM
To: Jakarta Commons Users List
Subject: Re: Shale + SCXML integration:


On 8/29/06, THOMAS, JAYANT (SBCSI) <jt8437@att.com> wrote:
> Hi ,
> Based on code for the shale handler implementation, it looks like we
are
> using a single instance of executor ,
<snip/>

Its a single executor instance per user per dialog instance, which is
a lot better ;-)


> On the faq I see the executor is
> not thread safe does this mean this implementation will not work ??
With
> mutiple servlet requests
<snap/>

If you're asking about the specific Shale usecase, I haven't
encountered the need. However, if there is going to be concurrent
access (or a possibility thereof), its best to synchronize on the
executor.

State machine execution is inherently linear, once a event is
triggered, processing must be completed before the next event can be
processed. There can be entire architectures to manage the event
queues (external to the engine), thats out of scope here.

If you're interested in the details of SCXML4Shale, there are ongoing
discussions about the dialog2 sandbox modules on the shale dev list
(dev@shale.apache.org), which might interest you (in which case, hop
on to that list, you can get upto speed here [1]). The dialog2 module
abstracts the state machine implementation out of Shale dialogs,
making it possible to use the Commons SCXML engine for driving Shale
dialogs.

You can follow the dialog2 modules in code here:

http://svn.apache.org/repos/asf/shale/sandbox/

-Rahul

[1] http://www.nabble.com/Shale---Dev-f15682.html


> Thanks
> Jayant
>

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


Mime
View raw message