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 03:16:40 GMT
Hi Rahul,

Two issues reported:

EventDispatcher#send
- inability to access context
- inability to access externalNodes (solved in prior thread - adding
externalNodes to method signature)

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?

    public void reset() throws ModelException {
        // Reset all variable contexts
        stateMachine.getRootContext().reset();
        // all states and parallels, only states have var. contexts
        for (Iterator i = stateMachine.getTargets().values().iterator();
                i.hasNext();) {
            TransitionTarget tt = (TransitionTarget) i.next();
            if (tt instanceof State) {
                ((State) tt).getContext().reset();
            } else if (tt instanceof History) {
                ((History) tt).reset();
            }
        }

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.  If so, I'm curious what implications this
would have on memory.  We are sharing our SCXML after digesting, and
prevent cloning and use getInstance() for each Executor.  Is this wrong?

Regards,


Mike



-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com] 
Sent: Tuesday, December 13, 2005 12:39 PM
To: Jakarta Commons Users List; mike@goomzee.com
Subject: Re: [SCXML] Concurrent users


On 12/12/05, Mike Sparr - www.goomzee.com <mike@goomzee.com> wrote:
> Rahul,
>
> Your code worked (from your personal snapshot) fine - thanks.
<snip/>

OK, thanks for the update :-)


> One issue
> we're now facing is handling concurrent users from multiple clients.  
> My goal is to use one scxml doc to manage app flow for all users.
<snap/>

Indeed, there will usually be only one SCXML document for a particular
application task (or flow, or dialog) -- which could be of arbitrary
granularity -- yet the per user (or per session) "instances" of the
state machine must be able to execute independently.


> It looks
> like there is one context and it's shared, so if we trigger an event, 
> it will affect any user.
<snip/>

Each user should have a separate Commons SCXML engine (or more
precisely, an instance of the org.apache.commons.scxml.SCXMLExecutor
class) assigned, and the events must be channeled to the appropriate
engine for the same user/session.


>  We have created a HashMap (in memory) to store
> key/handle to client for sending response, but are having troubles 
> dealing with concurrent users and their state.
>
> For example:
>
> Web request (state 1, event 3)
> IM request (state 2, event 1)
>
> Can the engine handle that or do you know how best to implement?  My 
> thought was to store state and last event per user, then navigate to 
> that somehow for their requests.  I assume there must be a better way?
>
<snap/>

We have a couple of published Commons SCXML usecases here:

http://jakarta.apache.org/commons/sandbox/scxml/usecases.html

Both the usecases are examples within a servlet container environment
(so similar to what you're attempting), and the SCXMLExecutor instance
gets created when needed, then cached and retrieved from the user's
session.

To summarize:

 * A SCXML document describes the state machine for a task/flow/dialog
in an application.

 * The org.apache.commons.scxml.model.SCXML class is the representation
of the document using the Commons SCXML Java object model.

 * An appropriately configured SCXMLExecutor instance creates a "live"
state machine (or engine) upon which external events may be fired.

 * SCXMLExecutor instances must be created per user/session and cached
throughout the life of the task/flow/dialog.

-Rahul


> Thanks,
>
>
> 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


Mime
View raw message