I'm hunting a bug that seems to only show up if
* prepare_cached is used.
* connect_cached is used.
* connections time out.
* the database driver is a bitch about leaking ressources.
Other interesting details:
* DBD::ODBC 0.30 + my sapdb patch.
* SAP DB: 7.3.0 BUILD 018-000-081-451
I've discovered that if I run something like:
while (1) {
connect_cached
prepare_cached
execute
finish
sleep(10 seconds longer than the DBMS timeout)
}
Then the system may leak ressources, with most drivers and setups you
will never notice; timeouts are (relatively) rare, a lot of drivers will
either correctly clean up in the call that fails (not common) or they
will be very tolerant with regard to the leaked ressources.
I've found that the sapdb odbc interface (possibly every DBD::ODBC user)
will leak connections when connections timeout.
The sapdb interface has an internal limit of around 10 connections per
proccess, so when 10 connections have timed out the driver blargs on
connect.
If I add: $dbh->disconnect; to the end of DBD::ODBC (executed when it
fails) the driver works perfectly even after a lot of timed out
sessions, now, my theory is that the disconnect frees up the cachedkids
and thus allows the ressources (dbh, sth)'s and their driver
counterparts to be freed.
However, I think the best place for the $dbh->disconnect in
connect_cached, there it will fix the problem for all drivers:
return $dbh if $dbh && $dbh->FETCH('Active') && eval { $dbh->ping };
eval { $dbh->disconnect; } if $dbh;
$dbh = $drh->connect(@_);
Hey Tim, how about it?
--
Regards Flemming Frandsen aka. Dion/Swamp http://dion.swamp.dk
