Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Reply-To: <mike@goomzee.com>
From: "Mike Sparr - www.goomzee.com" <mike@goomzee.com>
To: "'Jakarta Commons Users List'" <commons-user@jakarta.apache.org>
Subject: RE: [SCXML] Concurrent users
Date: Tue, 13 Dec 2005 16:34:32 -0700
Organization: GOOMZEE.COM
Message-ID: <03b401c6003d$c5cb5500$3daffea9@MSPARR>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <ce1f2ea80512131138m74a51470k7ab37b0d2580296@mail.gmail.com>

Hi Rahul,

I suspect the null context value is our implementation but will look
into that tonight.  If we cannot figure out, I do appreciate your
offering another set of eyes.  My 'helper' had originally stored the
executor per client type and not per client, hence the concurrency
issue... I think we got it sorted:

	private SCXMLExecutor getExec(String clientIdentifier){
		SCXMLExecutor
exec=(SCXMLExecutor)scxmlExecutorStore.get(clientIdentifier); 
		if(exec==null){
		    try {
	    	exec = new SCXMLExecutor(engine,new SimpleDispatcher(),
new SimpleErrorReporter());
	    		exec.setSuperStep(true); 
	    		exec.setStateMachine(scxml); 
	        	scxmlExecutorStore.put(clientIdentifier,exec);
	        }catch (ModelException me){
				me.printStackTrace();
		    }
		}
		return exec;
	}

Thanks and I will look at those use cases.  I had figured you must've
designed for more than a single threaded use.. After all, what if I want
to control all 10 of my microwaves at once!  :-)


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