Optimistic Concurrency

Frans also blogs about Optimistic Concurrency.

In a perfect world we would like to find ways to not to have concurrency problems, but I don't live in that world.

We need to deal with them, and we need to deal with optimistic concurrency errors.

Caching is a good example on why we need optimistic concurrency. If you have data cached, you cannot have any lock on it (you cannot have even a 'Pessimist Offline Lock'). When you read that data and update it, you'll need to apply optimistic concurrency. If you don't support optimistic concurrency you cannot cache.

On the other hands, your users don't like these kind of errors, so you need to avoid them. That's why you need to be able to check only for changes in some fields, and why a 'version' column is not always a good idea.

If you have columns with a lot of concurrent updates (for example, a product's inventory) then you'll probably need to have some rule to not to trigger the error when the values are different, of course making sure you apply the right operation to the column (for example, if the product inventory changed, unless there is not enough inventory for the operation I'm persisting, I don't need to raise a concurrency exception).