----- Original Message -----
From: "Gunther Birznieks" <[EMAIL PROTECTED]>
To: "Les Mikesell" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: "Tim Bunce" <[EMAIL PROTECTED]>; "Aaron" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Thursday, November 16, 2000 3:04 AM
Subject: Re: database access
> 1. I don't see the scenario you are talking about (dynamic connection
> pooling) actually working too well in practice because with most web sites
> there is usually peak times and non-peak times. Your database still has to
> handle the peak times and keep the connection open, so why not just leave
> the connection open during non-peak. It doesn't seem like it would really
> matter. Do you have a real scenario that this is a concern in?
This is not so much a problem where you have one or two databases
on a production server that is used by most pages - you are right
that you just have to be able to handle those connections. The problem
I see is on an internal intranet server where there are lots of little
special-purpose databases - separate calendar, forums, and assorted
applications, each with its own database and usage pattern. If
these all get used at once, the backend database server accumulates
a lot of connections. At the moment I don't have run-time user/password
based connections per user, but that would be an even bigger problem.
> 2. I do see adding a regex on the connect string to explicitly stop
> Apache::DBI from caching the connection being valuable.
That would probably be enough - or the other way around to
specify the one(s) you know should be cached.
> 3. As a plug, I had also suggested a couple years ago that I would like
the
> feature to be able to specifically not having the ping() method by
> Apache::DBI if the database had already been pinged within a set period of
> time.
That would fall into place if it timestamped the usage per handle and
also did a real disconnect on any that hadn't been used recently.
Les Mikesell
[EMAIL PROTECTED]
