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:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 2:13 PM To: Jakarta Commons Users List Subject: Re: Shale + SCXML integration: On 8/30/06, Craig McClanahan <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
