On May 8, 2009, at 10:52 AM, Clint Byrum wrote:
(T0) commit
(T2) update foo set value='b' where key=1
(T1) update foo set value='a' where key=1 (blocks on lock)
(T2) *must* wait on T1 for commit order
I agree that you're in a world of hurt here. As you said, this is a
broken serialization.. one that can only be solved by either
timeout, as you suggest,
A timeout is not required because all of these deadlocks can be
detected, using a "wait-for" graph (although there is no instance that
detects deadlocks across engines).
Transaction that need to be restarted do not have to wait. This can be
done immediately, because the other transaction(s) will probably
complete before the restarted transaction get that far again.
or full table serialization.
This is not a good solution because in a high concurrency environment
you will have a set of tables that are accessed by most transactions.
The result will probably not be much better than single threaded
execution on the slave.
*so*, what if we *do* add the table info as before, but *don't*
serialize on it all the time? when we finish a transaction early, we
check to see if there are unfinished transactions w/ any of the
tables we modified, and restart ours.
This would thrash horribly where people are incrementing a single
counter with lots of concurrent threads.
Thrashing is a problem with the "restart deadlocked transactions"
solution.
Mostly because transactions that wish to commit "too soon" must be
killed.
This problem could maybe be eased by starting transactions in the
commit order. So they run in parallel, but transactions that must
commit first are slightly ahead.
Note that transactions that don't have (row-level) update conflicts
will run through without a problem.
This is something that is would be extremely difficult to predict
beforehand. So the only answer is to go for it, and handle problems
later (by restarting transactions that try to violate the rules).
--
Paul McCullagh
PrimeBase Technologies
www.primebase.org
www.blobstreaming.org
pbxt.blogspot.com
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
