Why do so many programmers absolutely hate object prevalence layers?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.