Menu
Community /Pin to ProfileBookmark
@NogDogJun 17.2011 — #There's really no need to explicitly call mysql_close() at script close, since it automatically happens. The only reason to call it is if you want to close the connection [i]before[/i] you reach the end of the script (e.g. it's possible there will be a non-trivial amount of processing left in the script after you're done with accessing the database).
If you handle your DB connection through a class, you could add a __destruct() method to that class that closes the connection, then unset your DB object when done with it (though to be honest I'm not sure how "smart" the PHP compiler is, and if its optimization already releases/destroys objects that are no longer referenced after some point in the code).@NogDogJun 18.2011 — #It's probably part of the nature of PHP in a web environment, where it essentially launches a new PHP process for each page request, so once the script is done, its process is done and it releases (at least should ? ) all its resources. (It's a bit foggier now since most Apache hosts run a PHP module that is always running, so "process" might not be the best word for whatever it is that is spawned for each page request, but functionally it works to think of it that way.)
The MySQL extension in PHP does provide for a persistent DB connection (e.g. mysql_[b]p[/b]connect()) that might help avoid any resource contention, but my (very limited) experience with it suggests if you don't have everything done just right (including MySQL configuration), you can easily end up shooting yourself in the foot with a bunch of zombie MySQL processes. So I usually just fire up my MySQLi object, pass it around as needed, and don't worry any more about it -- at least until the day comes when some sysadmin tells me I'm using up too much MySQL process time. ?
[RESOLVED] Configure Default Tear Down?
If you’re anything like me you almost never use mysql_close(), even though it is the [I]correct
I am interested in some kind of configuration setting that will call mysql_close() (any arbitrary function really) at the end of each script.
Bonus points of you can find a setup function also ?
[FONT=”Courier New”][COLOR=”Sienna”]IMPORTANT:
Sign in
to post a comment4 Comments(s) ↴
0
@NogDogJun 17.2011 — #There's really no need to explicitly call mysql_close() at script close, since it automatically happens. The only reason to call it is if you want to close the connection [i]before[/i] you reach the end of the script (e.g. it's possible there will be a non-trivial amount of processing left in the script after you're done with accessing the database).If you handle your DB connection through a class, you could add a __destruct() method to that class that closes the connection, then unset your DB object when done with it (though to be honest I'm not sure how "smart" the PHP compiler is, and if its optimization already releases/destroys objects that are no longer referenced after some point in the code).
0
@NogDogJun 18.2011 — #It's probably part of the nature of PHP in a web environment, where it essentially launches a new PHP process for each page request, so once the script is done, its process is done and it releases (at least should ? ) all its resources. (It's a bit foggier now since most Apache hosts run a PHP module that is always running, so "process" might not be the best word for whatever it is that is spawned for each page request, but functionally it works to think of it that way.)The MySQL extension in PHP does provide for a persistent DB connection (e.g. mysql_[b]p[/b]connect()) that might help avoid any resource contention, but my (very limited) experience with it suggests if you don't have everything done just right (including MySQL configuration), you can easily end up shooting yourself in the foot with a bunch of zombie MySQL processes. So I usually just fire up my MySQLi object, pass it around as needed, and don't worry any more about it -- at least until the day comes when some sysadmin tells me I'm using up too much MySQL process time. ?