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,125 | Comments: 45,492

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.


  1. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - 5 hours from now
  2. RavenDB 3.5 whirl wind tour: I'll have the 3+1 goodies to go, please - 3 days from now
  3. The design of RavenDB 4.0: Voron has a one track mind - 4 days from now
  4. RavenDB 3.5 whirl wind tour: Digging deep into the internals - 5 days from now
  5. The design of RavenDB 4.0: Separation of indexes and documents - 6 days from now

And 11 more posts are pending...

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    05 May 2016 - Physically segregating collections
  2. RavenDB 3.5 whirl wind tour (14):
    04 May 2016 - I’ll find who is taking my I/O bandwidth and they SHALL pay
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats