ID: 20298
Updated by: [EMAIL PROTECTED]
Reported By: phpbug at tab1 dot clara dot co dot uk
-Status: Verified
+Status: Assigned
Bug Type: ODBC related
Operating System: *
PHP Version: 5CVS, 4CVS (2004-04-13)
-Assigned To:
+Assigned To: kalowsky
New Comment:
Assigned to the maintainer.
Previous Comments:
------------------------------------------------------------------------
[2005-07-27 10:57:57] t-yonetani+php at ergobrains dot co dot jp
Here's a patch written according to phpbugs at kevin dot offwhite dot
net's
suggestion(I hope space and tabs won't be damanged). We're using a
similar
version(just by replacing SQLGetInfo() with SQLGetConnectAttr()) on a
spare
machine, and odbc_pconnect() seems to be working so far. Uncommenting
out
the code for fixing #15758 is a bit scary, but I believe it should be
OK.
Index: php_odbc.c
===================================================================
RCS file: /repository/php-src/ext/odbc/php_odbc.c,v
retrieving revision 1.143.2.12
diff -u -r1.143.2.12 php_odbc.c
--- php_odbc.c 14 Jun 2003 03:37:30 -0000 1.143.2.12
+++ php_odbc.c 27 Jul 2005 08:47:05 -0000
@@ -2156,6 +2156,29 @@
}
/* }}} */
+/* {{{ is_connection_dead */
+static int is_connection_dead(odbc_connection *db_conn)
+{
+#if defined(HAVE_IBMDB2)
+#else
+ UCHAR d_name[32];
+ SWORD len;
+#endif
+ SQLINTEGER dead;
+ RETCODE ret;
+
+#if defined(HAVE_IBMDB2)
+ ret = SQLGetConnectAttr(db_conn->hdbc, SQL_ATTR_CONNECTION_DEAD,
&dead,
+ 0, NULL);
+#else
+ ret = SQLGetInfo(db_conn->hdbc, SQL_DATA_SOURCE_READ_ONLY, d_name,
+ sizeof(d_name), &len);
+ dead = len == 0;
+#endif
+ return ret != SQL_SUCCESS || dead;
+}
+/* }}} */
+
/* Persistent connections: two list-types le_pconn, le_conn and a
plist
* where hashed connection info is stored together with index pointer
to
* the actual link of type le_pconn in the list. Only persistent
@@ -2282,23 +2305,13 @@
* check to see if the connection is still in place
(lurcher)
*/
if(ODBCG(check_persistent)){
- RETCODE ret;
- UCHAR d_name[32];
- SWORD len;
-
- ret = SQLGetInfo(db_conn->hdbc,
- SQL_DATA_SOURCE_READ_ONLY,
- d_name, sizeof(d_name), &len);
-
- if(ret != SQL_SUCCESS || len == 0) {
+ if(is_connection_dead(db_conn)) {
zend_hash_del(&EG(persistent_list),
hashed_details, hashed_len +
1);
- /* Commented out to fix a possible
double closure error
- * when working with persistent
connections as submitted by
- * bug #15758
- *
- * safe_odbc_disconnect(db_conn->hdbc);
- * SQLFreeConnect(db_conn->hdbc);
+ /*
+ * now that we know the connection is
dead, just free
+ * the DBC handle without issuing
SQLDisconnect().
*/
+ SQLFreeConnect(db_conn->hdbc);
goto try_and_get_another_connection;
}
}
------------------------------------------------------------------------
[2004-06-04 22:06:49] phpbugs at kevin dot offwhite dot net
Well, after some additional research I have turned up what I think is
the exact cause of the bug, but I don't feel qualified to implement the
solution.
In the php code, at line 2271 in php_odbc.c (
http://lxr.php.net/source/php-src/ext/odbc/php_odbc.c#2271 ), php calls
SQLGetInfo() passing a parameter of SQL_DATA_SOURCE_READ_ONLY to try and
determine if the connection is alive or not. While this may work in
some odbc drivers, it is not the "official" way of asking if the
connection is dead. According to my driver supplier (
http://www-912.ibm.com/o_dir/odbcforum.nsf/8178b1c14b1e9b6b8525624f0062fe9f/B0CFDBA3D8DBAC0F86256EA80077D2B9?OpenDocument
) and the Microsoft's ODBC Programmer's reference (
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcodbc_connection_pooling.asp
), the correct method is to use SQLGetConnectAttr() to check the
Attribute SQL_ATTR_CONNECTION_DEAD.
Steps to reproduce:
1) Use PHP's odbc_pconnect() function with the iSeries ODBC Driver
for Linux.
2) Allow the connection to idle long enough for the Server to
disconnect.
3) Try and use the connection which was disconnected by the server.
Expected result:
1) PHP calls SQLGetConnectAttr() to check SQL_ATTR_CONNECTION_DEAD,
which returns SQL_ERROR.
2) PHP removes the connection from its internal list, creates a new
persistent connection, and returns that new connection to the php
script
3) call to odbc_exec() succeeds.
Actual result:
1) PHP calls SQLGetInfo() to check SQL_DATA_SOURCE_READ_ONLY, which
returns SQL_SUCCESS
2) PHP believes this to be a valid connection, and returns this
connection to the php script
3) call to odbc_exec() fails.
------------------------------------------------------------------------
[2004-04-02 10:48:58] phpbugs at kevin dot offwhite dot net
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
------------------------------------------------------------------------
[2002-12-18 13:59:45] [EMAIL PROTECTED]
I'm unable to reproduce this on the UNIX end of things. Anyone with a
Windows boxen working that can test this?
------------------------------------------------------------------------
[2002-11-07 07:41:49] phpbug at tab1 dot clara dot co dot uk
Make sure the odbc.check_persistent is on and that
odbc.allow_persistent is on. Set up a database connection called
dsnname
Run the script below (substituting [tabname] for a valid table name in
your database).
Check that you have persistent connections, ie with the webserver idle
make sure your database shows connections from the webserver.
Restart the database or kill the session belonging to the web server.
Re-run the script below and the odbc_exec fails with an error:
"connection not open" or smililar depending on your odbc driver.
I have found this effect to be the same with the Postgres odbc driver
and the Informix 3.30 odbc driver.
I presume that odbc.check_persistent is supposed to check that the
connection is still attached to the database before pconnect gives it
to the script?
<?
$dbconn = odbc_pconnect("dsnname","","");
$rid = odbc_exec($dbconn,"select * from [tabname]");
?>
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=20298&edit=1
