The only way I really see this working is in a threading environment. First
of all, for some databases database connections don't survive forking
(Oracle is the notable example here). Also, even if we could get forking to
work, we would still get the scaling problem we are trying to avoid.
Instead of Oracle keeping a huge list of persistent connections, the
Connection Pool would keep a huge list of persistent connections. In both
cases each connection would map to a Unix process and all these processes
would chew up OS resources big time!
----- Original Message -----
From: "Matt Sergeant" <[EMAIL PROTECTED]>
To: "Tim Bunce" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "Jeff Horn" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, October 27, 2000 7:02 AM
Subject: Re: Connection Pooling / TP Monitor
> On Fri, 27 Oct 2000, Tim Bunce wrote:
>
> > > Sounds like just a CORBA/RPC type thing. Wouldn't you be better off
using
> > > CORBA::ORBit?
> >
> > Maybe. I dunno. I don't actually need this stuff, I just want there to
> > be a solution out there for those that do. I'm waving my hands around
> > and pointing in various directions hoping someone will _do_ something!
>
> Hehe...
>
> OK, lets think about exactly what is needed here then. I figure Doug's
> Apache::DBIPool module (for mod_perl 2.0) is exactly the right
> architecture:
>
> 2 pools of connections (Busy and Waiting)
> New connections always taken from the head of Waiting
> Finished connections always replaced on the head of Waiting
> Threaded architecture (DBI::Oracle handles don't survive a fork)
> One thread for management
> One thread per connection once a handle has been supplied
> Some sort of timeout mechanism for connections if the pool is
> fully allocated
>
> Anything I've missed?
>
> If we don't go the threaded route, we can't easily expand and contract the
> connection pool I don't think - but I'd love to be proved wrong. Also an
> entire Apache server for the connection pool would be too much - the
> pre-forking server from the cookbook would be better. And it should even
> work on Win32 now...
>
> --
> <Matt/>
>
> /|| ** Director and CTO **
> //|| ** AxKit.com Ltd ** ** XML Application Serving **
> // || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
> // \\| // ** Personal Web Site: http://sergeant.org/ **
> \\//
> //\\
> // \\
>
