Hello,
While learning PHP I came across the following warning in the php manual and remembered one frequent error message in wikipedia (maximum number of database connections exceeded...):
There are a couple of additional caveats to keep in mind when using persistent connections. One is that when using table locking on a persistent connection, if the script for whatever reason cannot release the lock, then subsequent scripts using the same connection will block indefinitely and may require that you either restart the httpd server or the database server. Another is that when using transactions, a transaction block will also carry over to the next script which uses that connection if script execution ends before the transaction block does. In either case, you can use register_shutdown_function() to register a simple cleanup function to unlock your tables or roll back your transactions. Better yet, avoid the problem entirely by not using persistent connections in scripts which use table locks or transactions (you can still use them elsewhere).
Do we actually use persistent connections and is this problem affecting wikipedia?
greetings, elian
elian wrote:
While learning PHP I came across the following warning in the php manual and remembered one frequent error message in wikipedia (maximum number of database connections exceeded...):
There are a couple of additional caveats to keep in mind when using persistent connections. One is that when using table locking on a persistent connection, if the script for whatever reason cannot release the lock, then subsequent scripts using the same connection will block indefinitely and may require that you either restart the httpd server or the database server.
...
Do we actually use persistent connections
Yes...
and is this problem affecting wikipedia?
Mmm, sort of. We don't do any explicit table locking (ie, something like "LOCK TABLE cur"); tables are locked implicitly during queries, and locks should be automatically released when the query finishes even if our PHP script has meanwhile died and gone to process heaven, since there's no need to run an UNLOCK.
What does bite us sometimes is that a mysql connection can get stuck in an intermediate state between read calls where we end up being unable to do anything useful with it (you get "commands out of order" errors). You can't mysql_close() a persistent connection, and I haven't figured out a way to get out of the stuck state, so we have to do a new non-persistent mysql_connect() every time the Apache thread with the broken connection is reused. It's kinda inefficient, but it doesn't block the whole server.
-- brion vibber (brion @ pobox.com)
On Mon, Nov 25, 2002 at 04:59:45AM -0800, Brion VIBBER wrote:
Mmm, sort of. We don't do any explicit table locking (ie, something like "LOCK TABLE cur"); tables are locked implicitly during queries, and
Hm. I thought I saw some LOCK TABLE statements in the source; maybe it was only when a new database was being created.
Jonathan
wikitech-l@lists.wikimedia.org