ID: 33613
User updated by: kushmit at gmail dot com
Reported By: kushmit at gmail dot com
-Status: Bogus
+Status: Open
Bug Type: MySQL related
Operating System: redhat
PHP Version: 4.3.10
New Comment:
Hi-
(sorry if I was a bit harsh, before I really like PHP, but I was very
unpleasantly surprised by the behavior I am seeing :-) I did not intend
to flame anyone)
Someone (I think [EMAIL PROTECTED]) replied to me that this is not a bug
and I should RTFM and pass the 4th param to mysql_connect. I guess I
wasn't clear before, but I am passing that parameter in and it does not
appear to be creating a new link even though that's what I'm telling it
to do, which is why I filed this as a bug. Try it yourself and you will
see. The scenario is a lot of nested function calls and functions
referenced from other included php files. Sets of php functions grouped
into libraries and called by many other pieces of code. Operations
performed on multiple DBs. Etc.
I also got a response from someone ([EMAIL PROTECTED] - are you the rasmus
who started PHP? dude I did not mean to flame you, I have really gotten
a lot of benefit out of PHP over the years... but I still have
questions about this behavior) who said that mysql_close actually DOES
close the DB connection. There are multiple comments from multiple
users on the php.net wiki user comments that claim that mysql_close
actually only decrements the "resource counter" but maybe those
comments are no longer valid. I can say that based on the testing I am
doing, mysql_close does not seem to be behaving as you describe,
although I have not looked at the source. One question I would ask is
about this "reference count" - is mysql_close's operation dependent on
this count? What happens to the count as functions are called within
other functions?
Thanks.
Previous Comments:
------------------------------------------------------------------------
[2005-07-08 01:28:05] [EMAIL PROTECTED]
Wow, have you actually read the code you are flaming us about?
mysql_close() does a zend_list_delete() on the connection. The handler
for a list deletion is this function:
static void _close_mysql_link(zend_rsrc_list_entry *rsrc TSRMLS_DC)
{
php_mysql_conn *link = (php_mysql_conn *)rsrc->ptr;
void (*handler) (int);
handler = signal(SIGPIPE, SIG_IGN);
mysql_close(&link->conn);
signal(SIGPIPE, handler);
efree(link);
MySG(num_links)--;
}
This calls the libmysql mysql_close() function which closes the
connection.
I guess what you are referring to is the _close_mysql_plink() function,
but that is specifically for dealing with a persistent connection which
you have to explicitly define to me persistent by calling
mysql_pconnect(). If you want full control over when you open and
close your connection you obviously shouldn't open the connection as
persistent. Use the regular mysql_connect() call and you are in
control.
------------------------------------------------------------------------
[2005-07-08 01:24:41] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
RTFM. The 4th param to mysql_connect()..
------------------------------------------------------------------------
[2005-07-08 01:17:38] kushmit at gmail dot com
Description:
------------
Currently the way that mysql handles multiple DB connections on a
single server is not ready for prime time. It appears that mysql shares
all connections wth the same (or even different) parameters. Either way,
it is impossible to use PHP and mysql for serious DB apps without a way
to explicitly:
1. open a connection to a specific DB
2. use the connection PRIVATELY
3. close the connection to the specific DB
Currently, PHP and mysql do not allow this. There is a certain level of
connection sharing that ALWAYS occurs. This is extremely bad design. If
connections are implicitly shared and there is no way to establish a
private connection, then in a multiuser environment, where there are
many pieces of shared code making modifications to several databases,
it is impossible to predict what connections are "active" at a given
point in time. Relying upon a "reference count", which is essentially a
2-dimensional representation of connection status, in an environment
where multiple programs are opening and closing multiple connections to
multiple DBs results in unpredictable behavior. The whole idea that all
the Db connections on a given server should be managed by incrementing
and decrementing a counter is beyond belief IMHO - it will not work for
nay but the simplest of scripts.
In addition, the current mysql_close function DOES NOT perform the
typical housecleaning operations that would be expected of a "close"
function (all it does is decrement a DB reference count; no resources
are freed; no DB connection is actually closed). Several people have
reported this as a bug, but it keeps getting closed (?!?). IT IS A BUG.
Not being able to explicitly open and close DB connections is a HUGE
HOLE IN FUNCTIONALITY. If no one wants to fix mysql_close, the
function's name should at least be changed to
"mysql_decrease_reference_count" so people are not misled into thinking
that they can actually programmatically control DB connections...
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=33613&edit=1
