From: ahoward <ahoward@...>
Date: 2003-02-05T04:04:38+09:00
Subject: Re: postgres/drb experts [or hi eric ;-)]

On Wed, 5 Feb 2003, Eric Hodel wrote:

> try this:
> ruby -r postgres -e "Marshal::dump(PGConn.new)"

/usr/local/lib/ruby/1.8 > ruby -r postgres -e "Marshal::dump(PGconn.new)"
-e:1:in `dump': class PGconn needs to have instance method `_dump_data'
(TypeError) from -e:1

you are correct.  so it seems the ONLY way to design a connection pool for
PGconns is via proxy object

my initial test show that the typical connect/select/display pattern of a cgi
program will experience a speed up of around 2-8 times over making a direct
connection - assuming a smallish (< 3000 tuples) result set.  i'm not sure how
well the threading will scale respecting access to this one connection, but
priliminary tests make this look promising for 'normal' cgi type programs.

> If you get an exception, then DRb DTRT (Did The Right Thing) and wrapped the
> un-dumpable object in a proxy for you. :)

what a fantastic peice of code!  i bet it realizes this in any case where the
required module is an *.so since this would always be un-dumpable...

> Note that DRb does the right thing with this:
>
> require 'drb'
>
> DRb.start_service('druby://localhost:5000', File.new('server.rb'))
> DRb.thread.join

i assume this means you can define your server class in a file and serve it
that way?  does that then mean it would be inpossible to distribute, for
example, a log file?

-a

ps.  thanks for the reply.

-- 

 ====================================
 | Ara Howard
 | NOAA Forecast Systems Laboratory
 | Information and Technology Services
 | Data Systems Group
 | R/FST 325 Broadway
 | Boulder, CO 80305-3328
 | Email: ahoward@fsl.noaa.gov
 | Phone:  303-497-7238
 | Fax:    303-497-7259
 ====================================