Le lun 17/11/2003 à 18:16, Perrin Harkins a écrit : > On Mon, 2003-11-17 at 09:30, Jamie Le Tual wrote: > > An interesting test would be to put a sleep(20) adter the delcaration of > > the second database handle, then open a mysql shell and do a : > > show processlist; > > There's no need to go to all that trouble. Turning on debugging for > Apache::DBI will tell you when new connection are made. I already tried > it, and I can confirm that no new connections are being made. >
That's right, i did the same test and i confirm. > > Because Apache::DBI uses the > > DSN/username/password combination to uniquely identify a connection > > within its connection pool, the second connect() is getting returned the > > first handle, _and_ you are resetting AutoCommit on the fly. Because > > $db2 and $db1 are references to the same connection in the pool, $db1 > > will get the attributes you set on $db2. > > That isn't what's happening. Instead, asking for $db2 causes $db1 to > return to its original state, before AutoCommit was set. This shouldn't > happen, and it doesn't happen when you use connect_cached instead of > Apache::DBI. hum but connect_cached is quite a recent feature (my production servers are DBI 0.92) and i can upgrade yet. The last solution is to create a singleton object with a global $dbh that is called from a Database object. This way i control my cache, make my ping() and return the $dbh if exists and pinged. Thanks for your help. Christophe > > Apache::DBI doesn't make any effort to return database handles to their > original state when you call connect. If you change something, it > should stay changed. I think there is something strange going on deep > within DBI itself. > > - Perrin > -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
