According to the Java Persistent/Locking wikibooks*, the best way to deal with locks is to report the Optimistic Lock Error/Exception to the user.
The problem is that it’s not scalable. Suppose that I have many users who are likely to cause a lock with the same action. The user does not care about the lock error message.
In a nutshell :
- The best way is to disable all locks ?
- The best way is to report to the user the error lock message ? But the user must retry his action until it will work !
- The best way is to retry the transaction until there’s no lock ?
*
Handling optimistic lock exceptions
Unfortunately programmers can frequently be too clever for their own good. The first issue that comes up when using optimistic locking is what to do when an OptimisticLockException occurs. The typical response of the friendly neighborhood super programmer, is to automatically handle the exception. They will just create a new transaction, refresh the object to reset its version, and merge the data back into the object and re-commit it. Presto problem solved, or is it?
This actually defeats the whole point of locking in the first place. If this is what you desire, you may as well use no locking. Unfortunately, the OptimisticLockException should rarely be automatically handled, and you really need to bother the user about the issue. You should report the conflict to the user, and either say “your sorry but an edit conflict occurred and they are going to have to redo their work”, or in the best case, refresh the object and present the user with the current data and the data that they submitted and help them merge the two if appropriate.
Some automated merge tools will compare the two conflicting versions of the data and if none of the individual fields conflict, then the data will just be automatically merged without the user’s aid. This is what most software version control systems do. Unfortunately the user is typically better able to decide when something is a conflict than the program, just because two versions of the .java file did not change the same line of code does not mean there was no conflict, the first user could have deleted a method that the other user added a method to reference, and several other possible issues that cause the typically nightly build to break every so often.
The user will care about the message, because he wanted to do some modification, and the modifications have not been made. He will thus refresh the page to see the new state of the data, and will redo his modifications, or decide they should not be made anymore given the new state.
Is it a problem if two users modify an entity concurrently, and if the last modification wins, whatever the modification is? If it is a problem, then use optimistic locking, and inform your user when there is a problem. There’s no way around it.
If it’s not a problem, then don’t use optimistic locking. The last modification, if it doesn’t break constraints in your database, will always win. But having concurrent users modifying the same data will always lead to exceptions (for example, because some user might delete an entity before some other user submits a modification to the same entity).
Retrying is not an option:
Your problem could be explained with a car analogy. Suppose you choose to buy a car with a speed limiter, in order to make sure you don’t break the speed limit. And now you ask: but I don’t care about the speed limits. Shouldn’t I always disable the speed limiter? You can, but then don’t be surprised if you get caught by the police.