ID: 20298 Comment by: phpbugs at kevin dot offwhite dot net Reported By: phpbug at tab1 dot clara dot co dot uk Status: Open Bug Type: ODBC related Operating System: Windows 2000 Server SP4 PHP Version: 4CVS, 5CVS New Comment:
I'm seeing this problem on a Red Hat 9 system running PHP 4.3.5 on Apache 2.0. I have check_persistent and allow_persistent On, and phpinfo() reports 1 active persistent link. I'm not clear if the problem is in the ODBC Driver not reporting back to php that the server has terminated the link, or if PHP is not properly checking if the persistent link needs to be re-established, but I thought it wouldn't hurt to report the bug here and see what we can come up with. An interesting thing is that while phpinfo() reports only one persistent link, a netstat on the webserver shows 6 connections to the database server. When I load the page with the odbc_pconnect call, it will alternate between working and not working from pageload to pageload, so it seems that some of those connections are good and others are not, and php is not removing the bad connection from the hash list. The error message I get is: Warning: odbc_exec(): SQL error: [unixODBC][IBM][iSeries Access ODBC Driver]Communication link failure. comm rc=10054 - CWBCO1047 - The iSeries server application disconnected the connection, SQL state 08S01 in SQLExecDirect in /usr/local/apache/htdocs/test.php on line 15 Previous Comments: ------------------------------------------------------------------------ [2003-12-02 04:47:47] phpbug at tab1 dot clara dot co dot uk okay this was tested with: php4-win32-STABLE-200312020930 1st run: resource(2) of type (odbc link persistent) followed by the correct query results 2nd run (after killing db connection): resource(1) of type (odbc link persistent) Warning: odbc_exec(): SQL error: [Informix][Informix ODBC Driver]Communication link failure., SQL state 08S01 in SQLExecDirect in C:\InetPub\wwwroot\test.php on line 8 ------------------------------------------------------------------------ [2003-12-01 03:00:17] [EMAIL PROTECTED] Can you add 'var_dump($dbconn);' after that odbc_pconnect() call..? What does it output? (in the re-run) ------------------------------------------------------------------------ [2003-02-20 04:58:12] t_o_m_ at yahoo dot com Having reread all of this I see that nowhere have I mentioned I'm using IIS (ISAPI) not Apache, if that makes a difference? I thought when I put Windows in the OS box whoever read it would assume IIS. In answer to your question "no", the behaviour is the same if odbc.check_persistent is on or off. The point is when it is off I would expect it to be my responsibility to check the connection and would expect the error if I did not. I would expect that when odbc.check_persistent was on odbc_pconnect was supposed to check the connection for me if the connection it is about to return from its pool is dead then it should discard it and create a new one as when the pool is empty. Which is clearly not happening. ------------------------------------------------------------------------ [2003-02-18 12:01:03] [EMAIL PROTECTED] Well the nature of CGI doesn't really lend itself to supporting persistant connections. It's run when requested and then exited after that. So no data can really presist between pages that exists solely in the CGI. So this behavior only exists when odbc.check_persistent is turned on? ------------------------------------------------------------------------ [2003-02-17 10:08:22] t_o_m_ at yahoo dot com Yes still a problem under 4.3.0 I am using the ISAPI module. I don't believe that persistent connections are supported at all under CGI. So odbc_pconnect == odbc_connect which would give the illusion of working, although the connection would not actually be persisting. The first time you reload the page after killing the database connection you get: Warning: SQL error: No response from the backend; Subsequent reloads give: Warning: SQL error: Could not send Query(connection dead); ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20298 -- Edit this bug report at http://bugs.php.net/?id=20298&edit=1