commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <rahul.akol...@gmail.com>
Subject Re: SCXML Managing a large number of long-lived state machines.
Date Tue, 02 Jun 2009 16:52:25 GMT
Response below ...

On Tue, Jun 2, 2009 at 10:21 AM, JEFFREY Mark <Mark.JEFFREY@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-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message