Evan wrote:
"BV" == Brion Vibber brion@pobox.com writes:
Me> OK, so, I took my first crack at working on MediaWiki with an Me> attempt to check for cookies when logging in (bug #770011). BV> Great! I'm in the middle of the SoCal Linux Expo and will look BV> this stuff over when I get a chance... If some of the other BV> developers could look after this that'd be great.
I might have a quick look now.
Coolio! The patches I submitted are all independent -- none depends on another, that I can see, nor should they conflict -- and made against the HEAD for phase3. Some use global variables, so I'm going to wait till they're applied (or rejected B-) before trying to jigger with the $REQUEST hoohaw.
I'm going to try and cut my teeth on the transactions stuff. I figure I'll just try to find calls to wfQuery() with INSERT, UPDATE, DELETE in them, and wrap something like wfBegin()/wfCommit() around them, with wfRollback() for error conditions.
I'll probably miss 20% of them, and screw everything up. Should be a fun time.
Missing 20% is a lot better than missing 100%, which is what we're doing at the moment. It's really making a mess of our database, we often have to clean up inconsistencies manually. So everyone will be eternally grateful.
But before you start, I have to make sure you know about the dangers of transactions. These dangers were discussed by Brion and I on wikitech-l, in mid-August 2003 under the subject "Using HEAP tables":
http://mail.wikipedia.org/pipermail/wikitech-l/2003-August/thread.html
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.
AFAIK, killing threads by restarting the webserver doesn't pose a risk, because the MySQL connections will also be terminated, releasing any lock.
More information about user aborts is at: http://www.php.net/manual/en/features.connection-handling.php
This discussion, and patch submissions, are probably more on-topic at wikitech-l than at mediawiki-l. This post (and a couple of Brion's) have been cross-posted there.
-- Tim Starling
_________________________________________________________________ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp
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
"TS" == Tim Starling ts4294967296@hotmail.com writes:
TS> Transactions have to be guarded against user aborts. This TS> could be done either with a "critical section" model, where TS> user aborts are disabled for the duration of the transaction, TS> or alternatively a shutdown function could be used. The TS> shutdown function would rollback any active transactions.
OK, I'll take a peek.
TS> This discussion, and patch submissions, are probably more TS> on-topic at wikitech-l than at mediawiki-l.
Gotcha.
~ESP
wikitech-l@lists.wikimedia.org