You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by TonyTheFish <to...@gamesys.co.uk> on 2009/04/28 20:11:49 UTC
[SCXML] Saving and restoring execution state.
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?
--
View this message in context: http://www.nabble.com/-SCXML--Saving-and-restoring-execution-state.-tp23283182p23283182.html
Sent from the Commons - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [SCXML] Saving and restoring execution state.
Posted by TonyTheFish <to...@gamesys.co.uk>.
Many thanks for this Rahul. V. Useful.
Rahul Akolkar wrote:
>
> On Tue, Apr 28, 2009 at 2:11 PM, TonyTheFish <to...@gamesys.co.uk> 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?
>>
> <snip/>
>
> 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);
> states.clear();
> states.add(tt);
> }
>
> public void setContextVars(Map vars) {
> // reset retains builtin vars you mention above
> getRootContext().reset();
> getRootContext().putAll(vars);
> }
>
> 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 :-)
>
> -Rahul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/-SCXML--Saving-and-restoring-execution-state.-tp23283182p23315902.html
Sent from the Commons - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [SCXML] Saving and restoring execution state.
Posted by Rahul Akolkar <ra...@gmail.com>.
On Tue, Apr 28, 2009 at 2:11 PM, TonyTheFish <to...@gamesys.co.uk> 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?
>
<snip/>
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);
states.clear();
states.add(tt);
}
public void setContextVars(Map vars) {
// reset retains builtin vars you mention above
getRootContext().reset();
getRootContext().putAll(vars);
}
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 :-)
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org