Prevayler Perturbations

Ara said this:


…Prevayler is better and faster than classic OODBMSs because it’s simpler and aggressively caches everything: there’s no transaction API, no weird querying API, everything is just written to a log file, and so on. Basically the three main optimization techniques are: 1-lazy evaluation, 2-eager evaluation, and 3-caching. Prevayler uses 1 and 3 and wins, but you can apply the same techniques to RDBMSs too. So let’s say we come up with the same in-memory cached system, the same command-logging system like Prevayler, but with RDBMSs for the long term storage instead of serialization approach of Prevayler. I think that’ll be more attractive. And it’s possible right now: useHibernate for mapping objects to relational tables, use JCS (or a distributed cache or soon the JCache spec) for caching. The only missing part is the log-now/persist-over-night feature. That shouldn’t be hard to do. So let’s say you have a HibernatePersistenceManager class, you can decorate it with a LogNowPersistOverNightPersistenceManager which just writes a log file like Prevayler and persists them over the night (possibly triggered via a JMS queue or simply via Quartz job scheduler). The system should be lighting fast like Prevayler and yet RDBMS-based…

Prevayler has been great for getting everyone to question their persistence needs, and for stressing simplicity. However, the tacit assumption it seems to make (someone will correct me if I’m wrong) is that the only client of your application’s data is your application. The reason RDB’s are so ubiquitous and entranched is that there is a standard means of querying and updating them, using SQL. Its rare for a corporate system to have only one user of its data. Even if only one application is updating the data there are usually lots of reports based on it. If your data is accessible with a SQL statement, ‘anyone’ can write an ad-hoc query on it. If its stored in memory, or a serialized form then adding a report could mean changing your application code at worst, or at best making some kind of RMI call to it, which seriously raises the technical bar to writing a report. The other aspect of Prevayler that I am still unsure of is how it would work in distributed applications. Most distributed apps. have a single (or clustered) backend datastore, simply because there has to be somewhere that holds the unified picture of your data. The classic example being the airline reservation system where two agents both attempt to book the last seat on a plane. This can be handled because both transactions end up at the same datastore. Without some single point of reference, all concurrency and consistency checks would have to be after-the-fact.


2 thoughts on “Prevayler Perturbations

  1. Oh, come off it, Darren. That’s why you use Prevayler behind JMS instead of writing to it directly, which also gives you multiple points of access!

    Hopefully you caught the sarcasm here…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s