commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lee, Cheryl - ES/RDR -Gil" <Cheryl....@itt.com>
Subject RE: SCXML Managing a large number of long-lived state machines.
Date Tue, 02 Jun 2009 18:23:32 GMT
Mark,

We are using Rational Software Architect (RSA) to draw the UML state machines and "transform"
them to SCXML (a plugin available for RSA).  The SCXML output from RSA needs to be cleaned
up a little to be compatible with Apache netcommons, but it's nothing a short script can't
deal with.

There may also be other tools that generate SCXML, but I'm not currently aware of any others.

Good luck,
Cheryl

-----Original Message-----
From: JEFFREY Mark [mailto:Mark.JEFFREY@post.be]
Sent: Tuesday, June 02, 2009 11:07 AM
To: Commons Users List
Subject: RE: SCXML Managing a large number of long-lived state machines.


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.akolkar@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.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





This e-mail and any files transmitted with it may be proprietary and are intended solely for
the use of the individual or entity to whom they are addressed. If you have received this
e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely those of the author
and do not necessarily represent those of ITT Corporation. The recipient should check this
e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage
caused by any virus transmitted by this e-mail.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message