reDocument-Level Optimistic Concurrency in MongoDB

time to read 2 min | 313 words

I run into this blog post talking about how to handle optimistic concurrency in MongoDB and it brought to mind a very fundamental difference in the design philosophy between RavenDB and MongoDB.

If you’ll read the associated blog post, you’ll see guidance on how to build a simple optimistic concurrency using the MongoDB API. It looks like a relatively straightforward thing, but there is a lot of complexity going on here.

With RavenDB, we have decided that the responsibility of such tasks is on us, and not our users. Here is how you’ll write the same thing in RavenDB:

session.Advanced.OptimisticConcurrency = true;

And you are done. There are also options to set it globally (for all actions), for a particular session, as shown above or for a particular document or documents in a bigger transaction. About the only thing that we don’t handle is retries if the update failed, to allow you to re-run your business logic.

The reason I’m writing this is actually at the very end of the post:

This works just fine if I "remember" to include that Where clause correctly, but there's a better way if we want a general solution. For that, I'd do pretty much what I would have in the Life Beyond Distributed Transactions series - introduce a Repository, Unit of Work, and Identity Map.

This is exactly right. It looks trivial to do something like that when you are looking into a trivial scenario, but put it in a real application and the complexity sprouts. For example, try doing the same thing with multiple documents that need to change together. You have to implement quite a lot of code to do so (identity map, unit of work, hopefully not a repository Smile).

With RavenDB, all of that is just there and available for you. No need to do anything, It Just Works.

More posts in "re" series:

  1. (28 May 2024) Secure Drop protocol
  2. (16 Aug 2022) How Discord supercharges network disks for extreme low latency
  3. (02 Jun 2022) BonsaiDb performance update
  4. (14 Jan 2022) Are You Sure You Want to Use MMAP in Your Database Management System?
  5. (09 Dec 2021) Why IndexedDB is slow and what to use instead
  6. (23 Jun 2021) The performance regression odyssey
  7. (27 Oct 2020) Investigating query performance issue in RavenDB
  8. (27 Dec 2019) Writing a very fast cache service with millions of entries
  9. (26 Dec 2019) Why databases use ordered indexes but programming uses hash tables
  10. (12 Nov 2019) Document-Level Optimistic Concurrency in MongoDB
  11. (25 Oct 2019) RavenDB. Two years of pain and joy
  12. (19 Aug 2019) The Order of the JSON, AKA–irresponsible assumptions and blind spots
  13. (10 Oct 2017) Entity Framework Core performance tuning–Part III
  14. (09 Oct 2017) Different I/O Access Methods for Linux
  15. (06 Oct 2017) Entity Framework Core performance tuning–Part II
  16. (04 Oct 2017) Entity Framework Core performance tuning–part I
  17. (26 Apr 2017) Writing a Time Series Database from Scratch
  18. (28 Jul 2016) Why Uber Engineering Switched from Postgres to MySQL
  19. (15 Jun 2016) Why you can't be a good .NET developer
  20. (12 Nov 2013) Why You Should Never Use MongoDB
  21. (21 Aug 2013) How memory mapped files, filesystems and cloud storage works
  22. (15 Apr 2012) Kiip’s MongoDB’s experience
  23. (18 Oct 2010) Diverse.NET
  24. (10 Apr 2010) NoSQL, meh
  25. (30 Sep 2009) Are you smart enough to do without TDD
  26. (17 Aug 2008) MVC Storefront Part 19
  27. (24 Mar 2008) How to create fully encapsulated Domain Models
  28. (21 Feb 2008) Versioning Issues With Abstract Base Classes and Interfaces
  29. (18 Aug 2007) Saving to Blob
  30. (27 Jul 2007) SSIS - 15 Faults Rebuttal
  31. (29 May 2007) The OR/M Smackdown
  32. (06 Mar 2007) IoC and Average Programmers
  33. (19 Sep 2005) DLinq Mapping