Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,842

filter by tags archive

The subtle distinction between snapshot isolation and read committed

time to read 2 min | 312 words

I am using db transaction isolation levels for a reason here, they make it easier to reason about what is going on.

In short, RavenDB currently supports two storage engine options, Esent and Munin. Esent is what we usually use for production, and Munin is usually used for testing. We wrote Munin as a transactional, fully managed, storage engine a while ago. And it has mostly served us well, but Esent is what we usually aim for. That is the production use case.

We recently made a few changes that resulted in test failures on Munin, only in one run out of two dozens or so, but always worked with Esent.

Naturally, because of the random nature of the problem, I suspected the issue being a race condition in Munin. That happened in the past ,and obviously they are very hard to root out completely. But after finally isolating everything down to a simple test case (writing to two “tables” with associated information), I finally figured it out.

Munin is working just fine, it hasn’t got a spec of a problem. It is just that, when we built it, I built it to support Read Commited Isolation Level. While Esent is providing Snapshot isolation level. The code assumes snapshot isolation level at some pretty level. Obviously, this sort of thing shows up as a race condition, and it is extremely hard to debug, as anyone who ever dealt with those issues in RDBMS can testify.

So my task now is not to fix a bug in Munin, but to actually implement snapshot isolation. As it turned out, actually moving Munin from read committed isolation to snapshot isolation was a lot easier than finding the problem.

I am torn between being pleased that I found the issue, happy that Munin doesn’t have a bug and pissed that it took me that long.


Sean Kearon

So, does that move Munin closer to being suitable for production?

John Bloom

"I am torn between being pleased that I found the issue, happy that Munin doesn’t have a bug and pissed that it took me that long."

I think that developers have to deal with this emotion on a regular basis. And "taking a long time" is relative to the task at hand. Some problems taking 5 minutes is too long and I kick myself for not figuring it out quicker.


why have and maintain 2 storage engines while only one is aimed for production?


Munin is written in .net, while esent is a part of windows. The goal, from what i know, is to have a independent storage engine. Munin is just not ready for production. Yet.

http://en.wikipedia.org/wiki/ExtensibleStorageEngine http://ayende.com/blog/4686/raven-munin

Daniel Lang

@Edward: Because Munin can run in-memory, which is actually very handy from time to time (i.e. unit-testing).

Matt Warren


One reason is to have a way to run on Linux, although a version running on BDB might be a better option for that (see https://groups.google.com/d/topic/ravendb/WhuwS218-xg/discussion).

But the main reason for Munin at the moment is so that RavenDB can run in-memory, for unit tests.


@Daniel, @Matt thanks! [P.S. Nice blogs!]

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats