What are the ramifications of making AutoCommit => 0?
It going to bite me in the but later?
What are the pros and cons of using Apache::DBI::Cache over
Apache::DBI?
Thank for all of the help so far...
Boysenberry
boysenberrys.com | habitatlife.com | selfgnosis.com
On Feb 9, 2006, at 12:11 PM, Boysenberry Payne wrote:
After reading up on Apache::DBI::Cache it seems like it might solve
the issues, thanks.
I'll reply again if it doesn't...
Boysenberry
boysenberrys.com | habitatlife.com | selfgnosis.com
On Feb 9, 2006, at 10:03 AM, Torsten Foertsch wrote:
On Thursday 09 February 2006 16:14, you wrote:
I will be a list of them 5 at a time (I'm guessing one for each
child.)
Then as long as I only use that database no problem. As soon
as I switch databases which is the only thing that changes in my new
connections, I spawns all new database threads. So if I have
100 databases to connect to I get ( 100 * as many child apache
process
as the requests came in on). I don't think setting my max
connections 700+ makes sense especially since the remaining
connections
are shown as sleeping.
Is there a way to connect to more than one database without spawning
"extra" mysql connections?
I have not followed the thread. But
1) Apache::DBI::Cache could be of some help. Read the description
carefully.
It differs from Apache::DBI in when handles are cached.
2) Do you know that the DBD::mysql driver has a auto_reconnect
feature. If a
handle has AutoCommit=>1 and is running under mod_perl this is turned
on by
default. But the driver does not follow "use database" statements.
Hence,
once the mysql connection is lost the automatic reconnect is done to
the
database passed to the original DBI->connect. This hurt me badly while
developing Apache::DBI::Cache::mysql causing similar problems.
Torsten
