Hi Rahul, Thanks for the fast response, it looks like exactly what I was after (searched the mailing list but didn't find that thread). I'll try it tommorow when I get in the office (I'm at home now). cheers, Mark
p.s. do you know of any GUI's that can produce scxml as output? ________________________________ From: Rahul Akolkar [mailto:rahul.akol...@gmail.com] Sent: Tue 02/06/2009 18:52 To: Commons Users List Subject: Re: SCXML Managing a large number of long-lived state machines. Response below ... On Tue, Jun 2, 2009 at 10:21 AM, JEFFREY Mark <mark.jeff...@post.be> wrote: > Hello, > > > > We are writing a Java application that uses a state machine and feel > that scxml may be a good fit for us, although our use case is a little > different from the ones presented in the docs. > > > > The logic is the following: > > > > * We receive an event for a "tracked item" though JMS (using a > message driven bean which gives a separate thread for each event). > * If the item does not exist we create it otherwise we retrieve it > with the current state from the database. > * Set the state and, based on the state, set attributes of the > item (typically item attributes are copied from the attributes of the > event but not always). > * Save the item, the current state, and the event in the database. > > > > When we receive an event it is for any one of millions of items. I > suppose we need to construct a new state machine for each event and > (somehow) set the current state in the state machine. > > > > Some of the questions we have. > > > > When we receive an event we need to set the state machine to the current > state. Is there a special mechanism for this? - I tried the following > but it seems like a hack to me... > > > > public void setState( String stateString ) throws ModelException{ > > State stateToSet = (State) > getEngine().getStateMachine().getTargets().get(stateString); > > > > if(stateToSet == null){ > > throw new IllegalArgumentException( "State was not found: " > + stateString ); > > } > > SCXML stateMachine = getEngine().getStateMachine(); > > TransitionTarget initialTarget = > stateMachine.getInitialTarget(); > > stateMachine.setInitialTarget(stateToSet); > > getEngine().reset(); > > stateMachine.setInitialTarget(initialTarget); > > } > <snip/> Right, I wouldn't mutate the model itself (the 'stateMachine') since it is meant to be shared across all executor instances of the same state machine. In some cases, the status of the executor instance can be adjusted instead, as desired here. > Otherwise we could read in all the events (up to 20 per item) and apply > them sequentially to the item to calculate the current state each time. > > > > How should we manage the state machine construction? > > Keep a pool of statemachines (or Threadlocals) and use reset(). I guess > we would then need to replace any listeners. > > Construct a new statemachine each time (cost?). > <snap/> We had a similar thread about pooling executor instances about a month ago. I'll point to that here, please follow this link: http://markmail.org/thread/7rzalbdmbtvhr4kq -Rahul > > > Thanks in advance, > > Mark Jeffrey > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
--------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
