I come soliciting opinions, for I have a design decision to make for my Yote project. This is a server that takes requests, processes data and returns a result. The data is statefull and the calls are atomic. The data is object based.

Given the atomic requirements and the fact that the server side data tends to be shared by different users, different server processess must coordinate their activities. I have devised two schemes to handle this : a master process model and a coordinating processes model.

Coordinating Process Model -

In this model, each server process runs the command issued by the client. Each process loads up the objects from the database and coordinates with other processes by locking the objects. This is the model that I've seen other web servers use. If a process fails to exit, a watcher process may be able to reap it and unlock all objects attached to it. Unfortunately this is slow and memory intensive. It's not exactly the same level of atomicity that I would like, either, as objects could be locked out of order by two processes so deadlocking is a possibility. The implementation for this is rather new and has not yet been put through the paces.

Master Process Model -

In this model, the server processes take incoming requests and puts those requests on a queue. A master process checks the queue and invokes the commands, one by one. It then takes the return values and stores them in a shared data structure. The server process checks this shared data structure using coordinated locking signals to detect if the master process is done executing the command. This model is over twice as fast as the coordinating model because the master thread easily caches object values and does not always need to load from the data store. The big drawback of this model is that a particular command could take a long time and one with an infinite loop could potentially strangle the system. The system does set a timeout that a particular command may run. I've been able to run this model months without any crash under light loads. There may be times a long running process must be run. This model doesn't directly address that.

Some other unthought of way

There is always an other way to do it. Maybe a model with multiple queues, one slow and one fast, that coordinate object locking. I guess this would be a bit of a hybrid method. <.blockquote>

Comment on multi process advice