Tim Starling wrote:
I was just putting a few finishing touches on my
simulateneous edit bug fix,
Yay!
and I have two quick questions for anyone willing to
answer them:
* Do HEAP tables in MySQL disappear on restart, requiring you to run another
CREATE TABLE query?
My quick test says no. The data all disappears, but the table still
exists and can be used the next time 'round.
The simultaneous edit bug occurs very rarely (maybe
once every few days),
Once every few days is SERIOUSLY WAY TO OFTEN. I was worried about it
when it had happened twice ever to my knowledge... If it's happening
regularly, this must be fixed immediately.
when two users pass the edit conflict check and then
simultaneously try to
update the article. No edit conflict is registered. My thinking went like
this:
* Can't lock the whole table because it's not worth the performance
degradation for such a rare error
* Instead use MySQL's user locks to provide synchronisation
Why not try wrapping it in a BEGIN / COMMIT block? Transactions are
designed for exactly this kind of thing.
* But PHP threads die all the time for no good reason,
so there is a risk
that a lock will be left unreleased. Due to persistent connections, the lock
will stay active indefinitely. Only the DB thread which created the lock can
release it.
Threads may also get stuck in a transaction, but it _should_ be possible
to get out of it by running a 'ROLLBACK' at the start of each run to
cancel anything that may have gotten stuck. (Warning: untested theory!)
Further, nothing has to lock; the first transaction to commit wins, and
any conflicting transactions will get an error when they try to commit,
or just vanish into the ether if the thread dies.
* If another thread tries to get the lock but times
out, it kills the
offending DB thread
Which is now doing something unrelated serving a different web request...
-- brion vibber (brion @
pobox.com)