I create an object that holds the status of a job. The job has many stages, some concurrent. Worker threads constantly monitor the status object to see if it's ready for the next stage to begin, if it is the perform the job, update the status object and end. Is it some form of pub-sub? Is there a java framework for implementing such a pattern?
Occasionally I want to serialise all the status objects to disk such that the whole thing can restart after reboot etc.
This looks like a problem for a State design pattern.
Take a look at Spring statemachine. They handle listening to state change and also allows you to persist the state.
Always looking for the right design pattern can sometimes be misleading. Sometimes you need to combine some aspect of several patterns. And sometimes it makes you just focus on the wrong problem.
This is not a state pattern, even if it's about the state of the object, because the intent of state pattern is to:
Allow an object to alter its behavior when its internal state changes.
You don't need a state pattern, just to manage the state of an object ! In your narrative, the workers (other objects) monitor the state of a job (object with a state), to see if they can start their activity. But you don't say anything about the need for the job to change its behavior.
Note: it could perhaps be interesting to use the state pattern to represent the job, if each state has a different behavior or if you'd gain to have a more complex state transition logic.
The intent of your pattern is more like an observer pattern:
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
But unfortunately, your workers are just doing the opposite: they poll the state instead of just waiting to be notified.
Very important note: maybe it's worth to consider using a java Condition to significantly improve concurrency, as the condition is a kind of observer pattern ?
As your one of your intent is to serialize the state, one could wonder if it's not about a memento pattern:
Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored at a later stage.
Well, you have the intent of serializing the status, and certainly, in a multithreaded application, you want to ensure proper encapsulation of the job state. So maybe you should have a look at this pattern to package this neatly.
No it's not a Pub/Sub. A pub/sub is a variant of the observer pattern, in which the subscriber subscribes to a publisher (exactly like an observer would register to an observable), but the publisher would not just notify that there's some change, but provide the data to be processed.
You could get a pubsub, if the workers would read their job from a queue and your status object would control what the subscriber could read from the queue.
In your case, you can certainly have a look at these patterns and apply (or get inspired) by some constructs. But your main focus should more on the concurrency design than on class design: should you use a semaphore to give access to a queue ? should you use a condition to get a more optimal flow of control between awaiting threads ? should you look for a lockfree queue ? could another synchronisation mechanism help ?
