the Save / Load feature is incomplete and the loaded STM doesn't continue where it was saved

[djack42]

Hi and Happy New Year !

I noticed that the events added to the queue aren't Saved and because of that, a new Loaded STM does not continue properly after a Load.

Also, because there is no way to know if the STM is done working (except if manually stopped depending on active / passive implementations) to be saved properly, the Save operation should happen only when the STM is not executing, because an action could fire some events.
The Save operation should wait until the current transition is completed, then save everything including the events queued.
This could be done by calling Stop (stop should wait until completion), then Save and finally Start if the STM was already running.

As I was saying in the issue #21 (comment),
I think a better suited design would be to store the StateMachine's datas in a Model (CurrentState, events queued, HistoryStates etc.) and then use this model with the Persistence implementation.

[ursenzler]

I agree, I'm working on splitting the state from the actual machine, but it's a bit tricky. Hopefully, I'll find time next week to get it running.

[ursenzler]

This is really a tricky one. In addition to extracting the state (current-state, history-states, queued events), I'd like to extract the definition from the runtime, too. And both things are subtly connected with each other.
I guess I need to implement a quick fix for the queued events so you get a running version in a reasonable amount of time :-(

[ursenzler]

What do you think about the idea that only a stopped state machine can be saved? Saving a running state machine would result in an exception.
This would simplify the implementation. And it makes sense for me as a user of the state machine.

[djack42]

I agree, the manual Save should be allowed if the machine is stopped.

But in my case, running inside IIS, the persistance is a way to have a stateless statemachine and should work even when running, only when a full transition is completed.
I'm actually doing it with an extension on SwitchedState and from there I'm calling Save.
If you throw an exception, this method will not work anymore.
If you wait for the transition to complete, a call to Save in SwitchedState will produce a deadlock.

In my opinion, the manual save and the automatic save for a custom persistance should be separated features. A stateless statemachine should automatically update the persistance when between 2 Fire() from the eventQueue (by notifying an extension or by calling an instance of an interface given at construct time)

[ursenzler]

I'll be able to solve this problem after I split the state machine into its three aspects: definition, execution, state. Until then, the best I can offer is the manual Save approach. But I can do that with the option to accept Saves when the machine is running. This isn't checked in the current version anyway.

[zanek]

Save() doesnt work for me either, and Load() fails also. Why can't there be a simple option to save and load. Doesnt make sense

[NullReferenceException: Object reference not set to an instance of an object.]
Appccelerate.StateMachine.Machine.StateMachine2.LoadHistoryStates(IStateMachineLoader1 stateMachineLoader) in C:\projects\appccelerate\repos\statemachine\source\Appccelerate.StateMachine\Machine\StateMachine.cs:359
Appccelerate.StateMachine.Machine.StateMachine2.Load(IStateMachineLoader1 stateMachineLoader) in C:\projects\appccelerate\repos\statemachine\source\Appccelerate.StateMachine\Machine\StateMachine.cs:319

[ursenzler]

@zanek do you use the latest official release or the pre-release?

[zanek]

I used the latest version. I ended up switching to Stateless, this library was to buggy and incomplete.

[ursenzler]

Loading and saving are reworked in version 5.1 and includes now enqueued events.