On Fri, 27 Oct 2000, Jeff Horn wrote:
> 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!
I don't think thats a 100% fair analysis. First off, forking doesn't use
any more RAM than threading until you start copying data. And I don't see
that much of a scaling issue - we'd have a pool of connections available,
each as a child. Since you could control the number of connections
produced you wouldn't have to worry about the scalability issues too much
- the problems with things like mod_perl are that there is one connection
per child, regardless of what that child is doing. A pool would allow you
to make that a lot cleaner, and less resource intensive. At least I think
so... Unfortunately I don't have a need for this right now, so I'm not
willing to put the hacking tuits into it. Sorry :-(
--
<Matt/>
/|| ** Director and CTO **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
