Recently in an interview I was presented with the following scenarios and was asked to suggest suitable approaches to deal with each.
Q: In a client-server application how do we maintain the state of each client request? To the purpose of restoring all processing to their prior state in case of an event like a server crash.
A: Suitable 'milestones' could be defined and when each is reached the application would persist the state of a particular interaction. And in case of such a server crash the server can 'reload' the last saved state and start processing from there.
Q: The scenario was modified to include multiple users/actors and simultaneous/synchronous requests.
A: Slight modifications to the above solution could give an optimal solution.
Q: This seemingly simple client-server application was modified to include distributed computing along with clustering of servers.
Q: And how do you implement transaction management in the above scenarios?
Anyone who can shed some light on these questions are welcome.
Its very hard to get into the head of an interviewer and it gets harder if the interviewer thinks he knows things but he doesn't!
Anyways, coming to your question:
I think the interviewer was trying to get into a large scale distributed database (like HBase, Cassandra) OR a distributed persistable cache like Voldemort, Terracota etc.
If you maintain your state in a distributed cache then multiple server instances can share the state and work upon it giving you the same experience as a single server would offer.
Solutions like terracota have capability to sync data in between JVMs in a native way.
I am seriously NOT interested in any implementation. The question never was regarding implementing it either. It was a higher level discussion probably regarding my approach when it came to 'distributed transactions' if there is anything of that sort?
Sincerely thanks for answering but I'm not really looking for an implementation, just an approach?