OK, so here’s what I consider to be an improvement over Optimistic Locking. You know, the one, where you have a @version@ field that is used to verify that the changes are based on the latest. Imagine a non-trivial object with tens of fields and a likelihood of these being edited concurrently -- it’s clear that the traditional approach breaks down and that we need a different solution.
I came up with just one like that and call it Differential Locking. And here’s how it goes.
- Have clients remember the received data with all fields and send it back along the new data
- In trivial implementations this means that the update endpoint is to expect an ordered tuple
- Dumb clients may send the entire objects, smart ones can restrict to the changed fields only
- The database is only to consider fields that were actually changed -- ignoring all the others
- This enables simultaneous changes by other clients to fields that our client has not changed
- Update fields on the condition that their current value matches the base value of the client
- This can be done individually or in one go, with or without locking the row in the database
- Now you can also provide more meaningful error messages and help resolving any conflicts
- However, the potential of conflicts is significantly lower so we can expect fewer disruptions
- That’s about it, now you can delete those pesky @version@ fields, this is supercool. Yay, I say.