Spring State Machine - How many should I create?

Question

When I receive a request on my API, I want to do a series of steps, each being a check or an enrichment. Each step could either succeed or fail. On Success, the next step should be carried out. On Failure, an end-step should be executed, and the flow is done. For that I have considered Spring State Machine, as it seems to fit the bill.

I have read up on the documentation and played around with it, but some things elude me:

1. Should there be a 1-to-1 relationship between a request and a State Machine, meaning that for every request, I make a new State Machine instance? Or should I somehow reuse a completed State Machine by resetting the machine for the next request?

2. What about cleanup of completed State Machines? There doesn't seem to be a way to destroy and clean a State Machine instance. If I create 1 per request, I've effectively introduced a memory leak, unless the framework somehow handles resources.

Uela

I'm not familiar with spring's implementation, but looking at the documentation suggests that each machine has an internal representation of its state (compared to the state being stored externally to the machine; ala State currentState = machine.start()). This would preclude using a single machine across multiple requests since a second request could occur before the first is complete - possibly causing some odd behaviour. – Pigpen

With that said; is the state machine necessary? If you're only checking that preconditions are being met; would a simple if (!firstSuccess) return failure; if (!secondSuccess) return failure; not be enough? – Pigpen

I think there are several designs that would support this flow. One of them would be SSM. So for trying it out, I chose that. I agree with you that there must be a 1-to-1 between requests and state machine instances. But that leaves the question of resource control. Should instances be recycled? Or should they be discarded? If so, how? – Uela

Is it possible for them to be recycled? Looking here I can't see anything that suggests an SM could be restarted, though the start function doesn't indicate that it can't be called twice - so I'm not sure. Secondly; the effort required for you to maintain a pool of SMs not in use seems to me a lot of work - I'd just discard them I think, and let the GC deal with it. – Pigpen

I'd probably profile that if performance is important, though. Not sure how much overhead is involved in building a SM, so it may be that creating a shared pool is more efficient. – Pigpen

I just want to know how to manage the State machine instances. What if I over time end up with thousands or even millions of completed instances? There must be a way to clean up or recycle, but I can't find it. – Uela

So long as you don't retain a reference to them, they'll be garbage collected. As long as you're not expecting thousands or millions of requests per second, the JVM's garbage collector should be able to deal with it. – Pigpen

You can store it in the session, as indicated in the documentation: docs.spring.io/spring-statemachine/docs/1.2.0.RELEASE/reference/… – Sesquicarbonate

Answer 1

There is no absolutely correct answer to your question so I just need to leave some comments here. State machine as a concept is so loose that it gives you so many different ways to do things.

1. Whole concept if steps one after another kinda relates to how tasks recipe was implemented. It executes a dag of tasks and if parent task fails machine enters into error state giving user a chance to fix things and request machine to continue. statemachine-recipes-tasks statemachine-examples-tasks. Might be that this kind of use case would be a good candidate to create a new recipe as it is pretty generic.
2. Framework should clear things after machine has been stopped and eventually jvm should clear garbage. If you find something abnormal, please file a gh issue and we'll fix things.
3. We have sample statemachine-examples-eventservice which is reusing machines but I'm currently re-implementing that sample(it works but should be implemented better) as I was told by our head-chef that what I did there is dump SPR-15042. Machines cannot be used with a session scope and things go south if rich object(which ssm is) is serialised.
4. It is relatively easy to do a combination of states and choices which would do your step flow. It's only question how much you want this to be re-usable(thus generic recipe would be a good thing, PR's welcomed :) )
5. What comes for error handling something I presented in a statechart in gh-240 is also something to consider.
6. There has been some questions if ssm could work as a more generic flow engine but it's probably something it's never going to be as it would be a completely new project. Thought most of a flows could be handled as a separate recipes.

Fleeman