Sam Tregar wrote:
> *** From dbi-users - To unsubscribe, see the end of this message. ***
> *** DBI Home Page - http://www.symbolstone.org/technology/perl/DBI/ ***
>
> On Mon, 29 Nov 1999, Tim Bunce wrote:
>
> > Ignoring 'thread' (unsafe for production use) and 'debug' modes, the
> > normal 'fork' mode means that each client gets a seperate ProxyServer
> > process. And because of that, clients have no way to share connections
> > with each other.
>
> Is that necessarily the case? Perhaps the parent server could handle the
> connection-pooling and hand off live connection to the forked child.
Well, for at least some database systems, you cannot hand off a database
connection
across a fork -- Informix springs to mind. The connection is private to the
process that
creates it, even if the fork() mechanism makes a copy of all the resources. There
used to
be circumstances under which a single connection could be passed off to a child
for the child
to use, but only as long as the parent never tried to use or close the connection
while the child
was using it -- and it was unsupported. And, in those versions of the software,
there was no
way for any process to have more than one connection open, so pooling wasn't
really an option.
The newer connection technology forbids even the backdoor loophole.
> That way you could get the best of both worlds - de-coupled clients and a
> shared pool of database connections.
>
> It seems to me that moving to a single-process architecture has some BIG
> downsides when you consider the wide variation in database query runtimes.
--
Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED])
Guardian of DBD::Informix v0.62 -- see http://www.perl.com/CPAN
#include <disclaimer.h>