RavenDB - concurrency exception without optimistic concurrency

Question

In our Raven DB instance, we periodically get concurrency exceptions. This has always puzzled me since we haven't enabled optimistic concurrency.

Google tells me that there is a scenario where concurrency exceptions can be thrown without optimistic concurrency enabled - where you have an index which calls LoadDocument() on a document of that type. This is indeed the case with our codebase.

However, the thread I just linked to does not suggest a remedial action. What should I do in when a concurrency exception occurs? Should retry logic work? Or should I do something else?

Answer 1

A concurrency exception is raised if 2 threads are racing to physically modify the same document at the same time. One thread wins, the other(s) receives a concurrency exception.

It is up to you to determine what to do with that scenario.

Choices of what you can do:

1. Nothing. Unhandled exception. No different than if the network dropped for a minute
2. Replay. Last in wins. Your document that errored was the last in, replay the request to overwrite all changes.
3. Notify. Trap the exception. Inform the user their request was not successful and for them to review their changes vs the current version of the document.
4. Merge. Diff the two documents, merge them together ala source control auto-merge
5. Hand merge. Present UI to the user that showcases both documents and allows the user to execute a 3-way merge

You could also build an intelligent system for doing this. Concurrency exception, attempt auto-merge, if good, all good. Auto-merge fails, return with notification to user "sorry we could not accept your changes, click here to compare your changes".