commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject Re: [SCXML] Saving and restoring execution state.
Date Wed, 29 Apr 2009 22:05:30 GMT
On Tue, Apr 28, 2009 at 2:11 PM, TonyTheFish <> wrote:
> I am considering using SCXML in a high throughput environment where I have
> many thousands of state chart instances - naturally this means that the
> instances have to be pooled which means that there has to be a way of very
> quickly saving a restoring state to an executor.  I see that I can serialise
> an SCXMLExecutor instance - but that would be too heavyweight for this kind
> on environment.
> There is a getCurrentStatus() but apparently no setCurrentStatus().  Also
> the Context object seems to have a variety of system defined objects in it -
> it's not immediately clear which if any of them I would need.
> What I was hoping I could do was something like:
> executor.setState("node one");
> executor.setContextVars(myVariableMap);
> But that doesn'te seem to be possible.  Has anyone tried using SCXML in the
> sort of environment I am describing?  How would you go about it?

The SCXMLExecutor keeps track of internal state that encompasses many
concerns beyond the current state(s) and the datamodel values (context
vars). These includes state of things such as invokes, histories,
listeners etc. With some amount of self-imposed application
constraints, it should be possible to be much more nimble than
serialization, and pool executors as you desire for example.

So lets assume that for a particular application, the only executor
state that needs to be maintained is the current state and the context
vars. If this assumption holds, then the two methods you indicate
above can be implemented along these lines to allow executor reuse:

public void setState(String state) {
    Set states = getCurrentStatus().getStates();
    TransitionTarget tt = getStateMachine().getTargets().get(state);

public void setContextVars(Map vars) {
    // reset retains builtin vars you mention above

Usually, there is a context scope-chain. You can flatten everything
out to have one global datamodel so only the root context needs to be
restored as in the method above. Heres a flat evaluator implementation
(replace MyEvaluator with the one you are using):

public class FlatEvaluator extends MyEvaluator {
    public Context newContext(Context parent) {
        return parent;

Obviously, above snippets assume that the applications follow the
mentioned constraints. Adjust snippets as needed :-)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message