On Wednesday, September 26, 2012, Daniel Kinzler wrote:
I see your point. But if we have the choice between lock contention and silent data loss, which is better?
This isn't really a choice - by default, when a statement in mysql hits a lock timeout, it is rolled back but the transaction it's in is not. That can also lead to data loss via partial writes in real world cases if not properly accounted for by the application.
Avoiding holding locks longer than needed really should be paramount. Developers need to adapt to cases where transaction semantics alone can't guarantee consistancy across multiple write statements. We're planning on sharding some tables this year and there will be cases where writes will have to go to multiple database servers, likely without the benefit of two phase commit. That doesn't mean that we should give up on consistancy or that we shouldn't try to do better, but not in exchange for more lock contention.