On 9-12-2009 13:56, Frank Millman wrote:
My first thought was to look into Pyro. It seems quite nice. One concern I
had was that it creates a separate thread for each object made available by
the server.
It doesn't. Pyro creates a thread for every active proxy connection.
You can register thousands of objects on the server, as long as your
client programs only access a fraction of those at the same time you
will have as many threads as there are proxies in your client programs.
This behavior can be tuned a little as well:
- you can tell Pyro to not use threading at all
(that will hurt concurrency a lot though)
- you can limit the number of proxies that can be connected
to the daemon at a time.
Then I thought that, instead of the database server exposing each object
remotely, I could create one 'proxy' object on the server through which all
clients would communicate, and it in turn would communicate with each
instance locally.
I think that this is the better design in general: access large amounts
of remote objects not individually, but as a batch. Lots of small remote
calls are slow. A few larger calls are more efficient.
Is there any particular benefit in using remote objects as opposed to
writing a SocketServer?
It saves you reinventing the wheel and dealing with all its problems
again, problems that have been solved already in existing remote object
libraries such as Pyro. Think about it: do you want to spend time
implementing a stable, well defined communication protocol, or do you
want to spend time building your actual application logic?
Regards,
Irmen.
--
http://mail.python.org/mailman/listinfo/python-list
