Hi Chris, i'm not sure if it helps, but you can avoid parsing the same
file multiple times.
You can parse the scxml network once and save the SCXML object. Then
you can create many instances of SCXMLExecutor and set the network of
each of them to be the pre-parsed SCXML object (using the
setStateMachine method).


On Mon, Oct 25, 2010 at 09:19, Christopher Dragert
<chris.drag...@mail.mcgill.ca> wrote:
> The scenario:  I have many different classes (call them type A) each with 
> their own unique SCXML state chart. Though designed to work together, type A 
> classes are necessarily separate because we need them to be used modularly. 
> Another set of classes (call these type B), each instantiate a subset of the 
> available type A classes.  Inside a type B class, events are manually passed 
> between the state charts in a broadcast arrangement.  Thus, there are many 
> different type B classes, each containing their own instances of several type 
> A classes that essentially operate as parallel state charts.
>
>  I am having problems with the efficiency of this arrangement.  I have two 
> questions:
>
> 1)  When a state chart is parsed and loaded, one of the steps is to create an 
> SCXML engine.  Is it possible to clone the engine?  In my scenario, each type 
> A class may be instantiated many times.  This means that the associated SCXML 
> file is parsed and loaded many times, causing a significant slow down at load 
> time.  Cloning an engine seems to offer a way around this.
>
> 2)  Is it possible to create an engine, then add a new state chart to the 
> engine, treated as though it was part of the first state chart but enclosed 
> in <parallel> tags?  In my scenario, this would allow my type B classes to 
> only have one execution environment for all of its instantiated type A 
> classes.  Since we don't know what type As will be contained in a type B, it 
> seems hard to do this by prebuilding scxml files that actually contain the 
> <parallel> sections.  All this could be done before the state chart begins 
> execution.
>
> Any other advice regarding running large number of SCXML files would be 
> appreciated!  Thanks for any help.
>
> Regards,
> Chris Dragert
>
>
> ---------------------------------------------------------------------
> 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

Reply via email to