commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Sparr - www.goomzee.com" <m...@goomzee.com>
Subject RE: [SCXML] Concurrent users
Date Thu, 15 Dec 2005 06:33:58 GMT
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:mike@goomzee.com] 
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:rahul.akolkar@gmail.com] 
Sent: Wednesday, December 14, 2005 10:39 PM
To: Jakarta Commons Users List; mike@goomzee.com
Subject: Re: [SCXML] Concurrent users


On 12/14/05, Mike Sparr - www.goomzee.com <mike@goomzee.com> 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: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message