Prevalence is a simple technique to provide ACID properties to an in-memory object model based on binary serialization and write-ahead logging. It works like this:

  • Start with a snapshot. Serialize the object model and write it to a file.
  • Create a journal file. For every call into the object model, serialize the call and its arguments.
  • When the journal gets too big, you're shutting down, or it's otherwise convenient, perform a checkpoint: write a new snapshot and truncate the journal.
  • To roll back or recover from a crash or power hit, load the last snapshot and re-execute all the calls recorded in the journal.

The precautions needed to make this work are:

  • Don't let mutable object references escape or enter the prevalence layer. You need some sort of proxy or OID scheme, as if you were doing RPC. (This is such a common newbie mistake it's been nicknamed the 'baptism problem'.)
  • All the logic reachable from a call must be completely deterministic, and must not perform business-logic-meaningful I/O or OS calls. Writing to a diagnostic log is probably OK, but getting the system time or launching an asynchronous delegate is generally not. This is so that the journal replays identically even if it's restored on a different machine or at a different time. (Most prevalence code provides an alternate time call to get the transaction timestamp.)
  • Writer concurrency introduces ambiguity in journal interpretation, so it is prohibited.

Is it because ...

  • people developed a bad taste for them after trying to use one on a project that wasn't well suited* to it?
  • Klaus Wuestefeld's strident advocacy turned people off?
  • people who like the imperative programming model dislike separating I/O from calculation, preferring instead to interleave computation with I/O and threading calls?
  • prevalence layers are so conceptually simple and so intimately bound to the characteristics of the framework they inhabit that they're usually custom-rolled for the project, which makes them too alien/nonstandard/risky?
  • it's just too hard to keep straight what you have to be careful not to do?
  • newbies' heads just seem to explode when faced with something that isn't the same kind of two-tier database-driven app they learned to write in school? ;)

*The entire data set fits in RAM, you don't need writer concurrency, and you don't need to do ad-hoc queries, reporting, or export to a data warehouse. With apologies to SQLite, prevalence is an improvement on save-files, not a replacement for Oracle.

  • Aha. I wondered if it had a name. It always made sense to me, I just never had a name for it.
    – greyfade
    Commented Sep 23, 2010 at 3:02
  • 9
    What are you talking about?
    – TheLQ
    Commented Sep 23, 2010 at 3:12
  • This is the first time I've heard of this. What is it?
    – Jonn
    Commented Sep 23, 2010 at 5:20
  • Explanation added. Commented Sep 23, 2010 at 18:52
  • 1
    Ohhh.. I know the concept but I've never done this before. Looks pretty nifty to me. I'm pretty sure it's not something a lot of devs "absolutely hate".
    – Jonn
    Commented Sep 24, 2010 at 10:59

4 Answers 4


I think some of the problem is that they have a VERY specific use case (your not suited reason). I have built and worked on systems that use this approach and when you have a problem that is actually this problem it can be a wonderful solution.

Another part is that it looks a whole lot like some of the more painful bits of custom data storage you used to find a lot of 10+ years ago and has some of the same pitfalls (think batch updated btreive for example) which brings in your "too custom" point, but also makes it difficult to find off the shelf parts that work politely with it.

The last part is that they can be damn difficult to query against in many cases and folks in general are pretty accustom to being able to get their answers right now.


I think you first need to demonstrate that so many developers absolutely hate them. I don't think that's the case. Consider that fowler, a while back, formalized a pattern of sorts for this here.

  • Yeah, I'm a bit confused. They look like a great tool if you use them for the correct reason. Commented Sep 23, 2010 at 19:08
  • I'm just saying this because I caught an absolutely amazing amount of grief over this from co-workers. Commented Sep 23, 2010 at 21:51
  • 1
    @Jeffrey Hantin: They sound lazy and closed minded. Commented Sep 23, 2010 at 22:48
  • 1
    Oh, and the actual cornerstone of the pattern is c2.com/cgi/wiki?TransactionTape Commented Sep 24, 2010 at 22:01

The answer to the question is that while the theory is simple the practice is not.

Just testing such a setup requires dozens of test cases, add in mutli process or multi threaded code and this jumps to hundreds of possible conditions that need to be tested, both for persistence and recovery.

Any transaction monitor such as CICS,Tuxedo, Weblogic, Websphere, JBOSS or .NET, will provide all these facilities in a clean and tested manner. And any database will provide "enough" transactional/persistence for most applications.

Its mostly a case of that wheel was invented and perfected a long time ago.

  • this, and the tendency of many "architects" to have one favoured "flavour" that they look to push onto anything, no matter how inappropriate that design might be for the problem that needs solving.
    – jwenting
    Commented Oct 3, 2011 at 10:12
  • @jwenting So does that fall under the 'strident advocacy' point? Commented May 20, 2013 at 22:45

The pre requisites sound a bit onerous to code around, especially with most systems not needing ACID compliance when running in memory. Overhead sounds a bit nasty too -- there is alot of state tracking involved there.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.