We all know about techniques to prevent db deadlocks - acquire locks in the same order, etc. But at some point, systems under pressure may simply suffer from deadlocks here and there. Should we simply accept that and always be prepared to retry when a deadlock occurs or should deadlocks be considered absolutely verboten and should we do everything in our power to prevent them?
+3
A:
The answer is yes.
You should do everything in your power to prevent them, but are you ever going to be satisfied that you've made them impossible?
Mark Peters
2010-08-26 13:29:21
A:
This will probably be closed, but the world is trending to NoSQL solutions to this problem, breaking problems up so that guaranteed consistency isn't required from the datasource meaning that locks aren't required.
Facebook would be a good example of this, it doesn't matter when everyone sees your update, or if different users around the world see different versions of your profile. As long as the update works or eventually fails, that is good enough.
Spence
2010-08-26 13:30:17
only in limited situations. read consistency is essential for many real life scenarios.
Randy
2010-08-26 13:37:44
What @Randy said. Do you want your bank to manage your account balance like Facebook?
Philip Kelley
2010-08-26 13:43:58
Or do you want retailers to manage inventory that way? "We thought we had that part in stock, but found out hours later we had oversold by 200."
JNK
2010-08-26 13:45:48
I know of three Australian banks who use DDD and CQRS for their transaction systems.
Spence
2010-08-26 22:00:54
+1
A:
Do everything in your power to prevent them, and be prepared to retry when they occur. :)
Keep in mind that "doing everything in your power" can mean things like queueing batch updates, making inserts into temp tables and then merging those into the main tables later and other non-trivial techniques. Be sure to check your transaction isolation level and your lock escalation policy.
TMN
2010-08-26 13:33:36