Hi Rahul, Please disregard. Our initial solution leveraged vars (response=foo) to be sent for processing response, hence the need for context. As we updated the EventDispatcher.send, we now leverage <send> body contents for all messaging thus no need. Our workaround was the only reason for the need, but since <send> works now, everything is peachy! :-)
Thanks, Mike -----Original Message----- From: Mike Sparr - www.goomzee.com [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 14, 2005 11:15 PM To: 'Jakarta Commons Users List' Subject: RE: [SCXML] Concurrent users Hi Rahul, I envision we use <send> two ways, one for sending information to client and other for passing information to application for processing. As such, we need to send along handle and user input to application so it can return response to client. It seems that the Listener somehow "loses" the context upon initial entry, but then when an event is fired by the user, it "finds" the contexts and has access to vars. Make sense? Mike -----Original Message----- From: Rahul Akolkar [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 14, 2005 10:39 PM To: Jakarta Commons Users List; [EMAIL PROTECTED] Subject: Re: [SCXML] Concurrent users On 12/14/05, Mike Sparr - www.goomzee.com <[EMAIL PROTECTED]> wrote: > Hi Rahul, > > Two issues reported: > > EventDispatcher#send > - inability to access context <snip/> Which is per design. Can you elaborate why the context should be accessible? > - inability to access externalNodes (solved in prior thread - adding > externalNodes to method signature) <snap/> Yup, fixed in SVN :-) > > SCXMLExecutor#reset > - reset method resets ALL context(s) > ? should have reset for only that user's context, but to do that, we > would have to instantiate an SCXML obj (stateMachine) for each as well > as executor? <snip/> > You mention "appropriately configured Executor" below. I wonder if > you suggest each Executor instance also has its own unique state > machine (SCXML obj) instance too. <snap/> Yes, the SCXML object is the in-memory representation of an instance of the state machine. The evaluation contexts hang off of each State within the SCXML object, and so the reset method is clearing the contexts for this instance of the state machine. For each new user/session, a new instance is called for (SCXML as well as SCXMLExecutor). > If so, I'm curious what implications this > would have on memory. <snip/> The SCXML Java object model is fairly lightweight. Since your usecase is in the servlet container -- and most web related frameworks / technologies have much higher requirements -- I don't see any cause for concern. -Rahul > Regards, > > > Mike > --------------------------------------------------------------------- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
