Mailing List Archive

Patch for Bug #770011
OK, so, I took my first crack at working on MediaWiki with an attempt
to check for cookies when logging in (bug #770011). I got all
flummoxed trying to upload the patch to SourceForge -- didn't you used
to be able to do that? -- so I'm just sending it here.
Re: Patch for Bug #770011 [ In reply to ]
On Nov 21, 2003, at 10:55, Evan Prodromou wrote:
> OK, so, I took my first crack at working on MediaWiki with an attempt
> to check for cookies when logging in (bug #770011).

Great! I'm in the middle of the SoCal Linux Expo and will look this
stuff over when I get a chance... If some of the other developers could
look after this that'd be great.

-- brion vibber (brion @ pobox.com)
Re: Patch for Bug #770011 [ In reply to ]
>>>>> "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.

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.

~ESP

--
Evan Prodromou <evan@wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide
Re: Patch for Bug #770011 [ In reply to ]
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