Tim Starling ts4294967296-at-hotmail.com |wikipedia| wrote:
Transactions have to be guarded against user aborts. This could be done either with a "critical section" model, where user aborts are disabled for the duration of the transaction, or alternatively a shutdown function could be used. The shutdown function would rollback any active transactions. However note that installing a shutdown function effectively disables user aborts anyway. When there is a shutdown function, PHP only checks for pending user aborts on output -- in our case, once per run.
If a PHP thread dies while a transaction is active, any locked tables will remain locked indefinitely. The wiki will effectively become read-only until a developer manually flushes the lock. We've seen this happen on the English Wikipedia.
Your last paragraph is not quite true (or shouldn't be at least). If the thread really dies (that is, segfaults) the mysql connection will be closed, locks released and transactions rolled back. If the script dies in a "nice" way, with die() or equivalent, then what you describe will happen.
This opens up for a very simple solution. One wfQuery("START TRANSACTION") at the top of wiki.phtml, and one wfQuery("COMMIT") at the end of it. Top off with a call for wfQuery("ROLLBACK") in the shutdown function. There you have a complete, safe and simple implementation. One *may* want to use more fine-grained transactions to reduce the amount of time spent in a locked state, but I wouldn't spend too much time on that until it's clear that it's necessary. Especially since locked time isn't lost time, since there's plenty of work for the db server to choose from.
// E23