I need to serialize a Java Process (to persistent storage such as a disk) followed by killing it.
Then at a later time De-serialize it and re-resurrect it at a later date.
Constraints:
- I already have a set of process that I want to add this feature to.
- I am therefore looking for a solution that is minimally invasive.
- The processes have code that will re-establish connections to resources such as sockets, DBs etc.
- What I need to do is persist the thread statuses, variables, objects, etc.
NOTE:
- I have decent knowledge of the issues surrounding the serializing of an Object Graph.
- Many years ago I’d conceptually figured out how to do this using AspectJ but I can’t find my notes
- This question pertains to Java Process only — so the solution would work on say a JVM running on OSX, Linux, or Windows
- The process in question would be refactor-able to achieve this functionality.
Classes like
Thread,Socketand otherjava.ioclasses do not implementSerializablefor a purpose. Having said that, the best thing I can recommend to you as a refactoring hint is to make your applications provide a clean way of saving and restoring state when triggered. As you cannot recreate the state of threads or network connections as such, depending on the problem domain you might be able to write your classes in a way which makes them transaction-safe plus you can record running transactions on shutdown and make sure that they are rescheduled/restarted after wake-up/deserialisation.(Disclaimer: Even after you have edited your question it is so unspecific that I can only offer an educated guess and general hints in the following.)
First and foremost you are dealing with a design question here. AOP will probably be helpful in implementing this concern (it is clearly cross-cutting) after you have solved your design issues. E.g. you could have an aspect add an interface like
Interruptableto the classes in question and connect it to functionality implementing the desired behaviour, e.g.ObjectState interrupt()andvoid continue(ObjectState)(all class, interface and method names are pure invention). So while you will not be able to freeze your applications in the rather magic way you seem to describe, with some hard work you might be able to save the application state in a way which at least helps you re-start it in a way which restores logical state (not technical one like socket connections, thread IDs) so the application can continue with whatever it has been doing before you froze it.E.g. a download manager can continue downloading a file because it has previously recorded its logical state: download source, temporary file name and number of bytes already written. So even though a new network connection needs to be established to continue the download, the “transaction” does not need to restart from scratch. I assume that is what you want.
Writing down this monologue, it seems to me that part of the functionality I was describeing should probably exist in existing application servers or containers (I am not an expert there).
So when you have finally worked out a way for all relevant application classes to persist their logical state, come back and ask another question about how to best do what you want using AspectJ or so. 🙂