commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "JEFFREY Mark" <>
Subject SCXML Managing a large number of long-lived state machines.
Date Tue, 02 Jun 2009 14:21:54 GMT


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)


        if(stateToSet == null){

            throw new IllegalArgumentException( "State was not found: "
+ stateString );


        SCXML stateMachine = getEngine().getStateMachine();

        TransitionTarget initialTarget =





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?).


Thanks in advance,

Mark Jeffrey

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message