I cringe at the thought of using a Last In Wins update policy, it just smells bad. Maybe because I've been involved in alot of database development, or maybe I've worked on systems with reasonable levels of concurrent access that I hate leaving things to chance.
An argument for Last In Wins, is that the user may not know why there update has failed etc. We could approach this through useful messages or improved usability.
Another would be that why build optimistic locking when the simplest thing that could possibly work should suffice in most cases.
Well the cost of building it in is not high, it has good support in most orm including hibernate.
In reality the actual number of cases where multiple user transactions may attempt to update the same row should be very rare, but that is no reason to give up on optimisitc locking.
Databases are there to provide ACID proof transactions, Atomicity, Consistency, Isolation and Durable.
If we choose Last In Wins we are at a much higher risk of corrupting the data, if updates on tables can occur that don't update all columns the way is open for inconsistent updates. It feels so wrong to have a database that provides ACID transactions yet we can partially thwart it's goodness by not using pessimistic or optimistic locking policy.
For some systems or certain areas of a domain it may be fine. eg. updating a user's profile.
If you are going to mix it up, at a minimum ensure that Aggregate Root Entities use optimistic locking since they are more likely to have concerns (state or behaviour) that depend on it's children. eg. summarised data that needs to be updated, or invariants that need to be validated before transaction completion.
In general I would prefer to standardise on optimistic locking.
0 Responses
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.