commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: Shale + SCXML integration:
Date Tue, 29 Aug 2006 13:51:25 GMT
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


Mime
View raw message