On 8/29/06, THOMAS, JAYANT (SBCSI) <[EMAIL PROTECTED]> 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 ([email protected]), 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
