From: Robert Klemme <bob.news@...>
Date: 2003-03-07T19:15:29+09:00
Subject: Re: DRB and threads


"Brian Candler" <B.Candler@pobox.com> schrieb im Newsbeitrag
news:20030306234411.GA43350@uk.tiscali.com...
> If I understand this rightly, then I can't see how you can use this with
any
> object which carries state unless you rewrite or wrap all the methods to
> make them thread-safe. Is this correct?

Yes, that's correct. Since the server can hand the instance's reference to
multiple clients (or a single multithreaded client) you must take measures
to handle this.

> Anyway, the pattern I really want to implement is a pool of objects, with
> the method call handed to any free object (and that object does not get
> another request until it has finished handling the first one).

> The aplication is that I have a database front-end class where each
instance
> keeps a DBI handle open (amongst other things) but each method call is
> independent of the previous one, i.e. there's no state kept
> *between* calls, other than inside the database itself of course. So
> incoming requests can be farmed off to any object which is free.

Then I suggest to use a variation of the facade pattern: You have a single
instance that is known to clients.  This instance internally holds a pool
of instances that do the real work.  Methods of your facade fetch an
instance from the pool hand the request over to this, return the results
and put the instance back into the pool.  Pool access must be synchronized
of course.

> Do I have to write a wrapper object which duplicates every method in my
> database class (or method_missing)? Or is there a simpler way of handling
> this?

method_missing is not a bad idea, I guess.

> Another solution would be if I could run a DRb server under FastCGI, so
that
> I had a pool of processes (maintained by Apache) and requests would be
> farmed out to those processes. Is that possible?

Possibly.  Although multiple threads should be more efficient than multiple
processes.

    robert