commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Sparr -" <>
Subject RE: [SCXML] Concurrent users
Date Thu, 15 Dec 2005 06:14:58 GMT
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?


-----Original Message-----
From: Rahul Akolkar [] 
Sent: Wednesday, December 14, 2005 10:39 PM
To: Jakarta Commons Users List;
Subject: Re: [SCXML] Concurrent users

On 12/14/05, Mike Sparr - <> wrote:
> Hi Rahul,
> Two issues reported:
> EventDispatcher#send
> - inability to access context

Which is per design. Can you elaborate why the context should be

> - inability to access externalNodes (solved in prior thread - adding 
> externalNodes to method signature)

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?
> 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.

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.

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


> Regards,
> Mike

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message