Question about 'remote objects'

[Irmen de Jong]

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.