A corollary to that is that I've had reports that DBD::ODBC's ping doesn't necessarily work correctly with Oracle8, so there *may* be some issues with SAP, too, but I'm unsure. The problem is that DBD::ODBC assumes prepare() will contact the server, but Oracle 8 may not actually do that, until you "describe" the query (according to what I've seen in Tim's code).
Jeff > -----Original Message----- > From: Tim Bunce [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 18, 2002 6:39 PM > To: Flemming Frandsen; DBI developers > Subject: Re: ping vs. connect_cached & prepare_cached > > > > 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. > > >
