> 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)
> }
Can you show me the actual code?
> 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?
The disconnect should be triggered automatically when the connection object
is destroyed. Please enable trace and try to confirm that DESTROY is being called.
Tim.
