ID: 14254
Comment by: klightse at water dot ca dot gov
Reported By: cedric dot boudin at iconmedialab dot com
Status: Closed
Bug Type: Informix related
Operating System: Solaris 8
PHP Version: 4.0.6
New Comment:
Well, we came up with a hack to work around this miserable bug. You
can see our environment listed in the posting we made above. The
following is our assessment of the problem and the work around
solution:
--------------------------------------------------------
ifx_connect call (from Informix CSDK) fails on repeated queries. The
problem seems to be that it believes that the returned connection ID is
already in use!
The informix error follows:
-439 Database server is currently processing an SQL task.
You attempted to call an SQL routine or attempted to execute an SQL
statement within a signal handling function/routine or a callback
function/procedure. Use only the sqldone() and sqlbreak() library
functions inside your INFORMIX-ESQL/C callback function. Use only the
ECO-SQD and ECO-SQB library routines inside your ESQL/COBOL callback
procedure. In addition, if you want to unregister your callback
function in INFORMIX-ESQL/C, you can invoke the sqlbreakcallback()
callback registration function within your callback procedure. If you
want to unregister your callback procedure in ESQL/COBOL, you can
invoke the ECO-SQBCB callback registration routine within your callback
procedure.
Found reports of a PHP bug that seems related (#14254).
Bug goes back years, no fix reported. Just "make system faster".
I found anohter related(?) bug (#18534 ifx_close() leaves open
session)
Docs on ifx_connect show the following:
"In case a second call is made to ifx_connect() with the same
arguments, no new link will be established, but instead, the link
identifier of the already opened link will be returned."
Theory is that ifx_close doesn't immediately close the connection.
Since the parameters in ifx_connect are always the same (user, passwd
and database), the next ifx_connect() tries to use the existing
connection, and sometimes fails (busy, in process of closing, ???)
Our fix: Try using "rotating users" - we set up 10 "bdtdb" users
(bdtdb0-9), all with same uid/passwd on Solaris system. Use different
one for each connect, the chance of colliding with an open/bad
connections drops a lot (doesn't go awasy completely).
Here's our code:
// This is a hack to work around
// the bug 439 (see Informix docs
// - finderr 439) that relates to
// PHP concurrency problems with
// Informix.
// In essence, we are recycling
// usernames so that we can convince
// Informix to issue a new resource id
// for our connection, thus preventing
// collisions. Note that collisions
// could still occur, but it would be
// much less likely. To make it even
// less likely, use more user names.
// This is the best we can do,
// since no one here has the
// time to debug the PHP/Informix modules.
function getDBUserName() {
global $HTTP_SESSION_VARS;
$NUM_USERS = 9;
$user_index = $HTTP_SESSION_VARS['user_index'];
// First time in
if (!$user_index && $user_index != 0) {
// $user_index = rand (0,$NUM_USERS);
// Random # between 0 and numusers
// This doesn't work even if it is
// seeded. Always starts on
// same number. Go figure.
$user_index = 0;
}
else {
$user_index = $user_index + 1;
if ($user_index > $NUM_USERS) $user_index = 0;
}//else
$HTTP_SESSION_VARS['user_index'] = $user_index;
return ("bdtdb" . $user_index);
}//getDBUserName()
//----------------------- Defined Vars -------------
$db_userid = getDBUserName();
$db_password = "fish911";
$db_database = "[EMAIL PROTECTED]";
// ---- Then use these in your connection to db.
// We are definitely not using persistent
// connections.
Tested this hard - could not make it break, even with heavy load.
Prior to fix, even light loads would create error.
Previous Comments:
------------------------------------------------------------------------
[2003-07-10 20:04:59] shai at shai dot org
I am using AIX4.3.3
Apache 1.3.22
PHP 4.3.1
Infrmx 7.3.1
Same problem, I am using the RS6000-M80 and I can reproduce the
problem
when I am the only person on the machine with small queries. I suspect
that this maybe an apache related issue. I notices that my apache has
spawned off 20+ children. So I started messing with the persistant
connection and timeout options, seems to have made the problem go away
for now. Even with multiple hits, apache doesn't seems to be spawning
more than 12 helpers.
Any comments from anyone?
------------------------------------------------------------------------
[2003-06-09 14:59:52] klightse at water dot ca dot gov
We are seeing the same bug. We just discovered it, two days before we
go into production. Talk about a timing issue....
Solaris 8
Apache 1.3.26
PHP 4.3.0
Informix 9.3uc3
If anyone knows the solution, please post it. We are going to have to
reprogram this site in JSP if we can't fix it.
------------------------------------------------------------------------
[2003-04-25 12:44:15] jswinborne at nwc dot edu
I am also experiencing this error. It seems to come and go randomly.
We are using PHP 4.2.1 with Redhat 9.
------------------------------------------------------------------------
[2003-02-23 20:32:39] neil dot wilkinson at transport dot nsw dot gov
dot au
This problem still exists and does indeed occur most often when the
database is busy.
However, there will always be situations where the database is busy, so
increasing performance will only help in some situations.
The problem appears to be to do with how PHP responds to the callback
functions. I believe that the apache and native ESQL libraries are bug
free in this respect because embedded perl, etc (hitting the same
database from the same machine using the same ESQL libraries) never has
this problem.
Is there anyone out there that understands the PHP IFX source code and
could fix the callback functionality. Failing that I could have a go
if given some assistance.
FYI, the server specifics are:
Solaris 2.6
Apache 1.3.27
PHP 4.2.3
ESQL 7.24.UC6
Informix 7.30.UC8
Please do not close this bug unless the problem has been solved.
Several instances around this bug have been closed by the solution
"upgrade hardware" where there is clearly still an error to be fixed.
Regards,
Neil Wilkinson
--
------------------------------------------------------------------------
[2002-07-06 17:35:16] pschmidt at naxs dot net
Well, I see this problem every time I run my scripts. We are running:
PHP 4.2.1
Apache 1.3.24
ESQL/C Version 9.51
Some of the Informix tables are large.
Since I am seeing this consistently, I would really like to see a fix
to this problem. My scripts are somewhat complicated. But I can
reproduce the problem with a simple script. It contains:
-----------------------------------------------------------
<?php
// create connection
$connection = ifx_connect("<deleted>", "<deleted>", "<deleted")
or die("Couldn't create connection.");
// create SQL statement
$sql = "SELECT f1, f2, f3, f4, f5, f6, f7, f8, f9, f10, f11, f12, f13,
f14 FROM T1 where f1 < 500";
// execute SQL query and get result
$sql_result = ifx_query($sql,$connection)
or die("Couldn't execute query");
// format result in HTML table
ifx_htmltbl_result($sql_result,"border=1");
// free resources and close connection
ifx_free_result($sql_result);
ifx_close($connection);
?>
-----------------------------------------------------------
To reproduce this, I hit the refresh button on the browser before the
page had downloaded.
I tried switching it to pconnect and still got SQLCODE=-439 failures.
Although the table is big, I think the load was light (I tried this on
a Saturday afternoon.)
Anyone that has questions, feel free to send them to me at
[EMAIL PROTECTED]
Best Regards,
Paul Schmidt
Action Web Creations
------------------------------------------------------------------------
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/14254
--
Edit this bug report at http://bugs.php.net/?id=14254&edit=1
