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:[EMAIL PROTECTED] 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) <[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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
