[Seaside] Prevayler

[Frank Sergeant]

Josh Flowers <joshflowers@mac.com> wrote:
> Avi Bryant wrote:
> > On Sun, 17 Mar 2002, Josh Flowers wrote:
> >>I'm certainly no expert, but the idea behind Prevayler intrigued me
> >>enough to look into it so I'll tell you what I've discovered so far...

Me too.  I appreciate it being called to my attention.

> > I don't think so - the strength (and weakness) of Prevayler seems to be
> > that it forces you to funnel all mutations through a single point.
> > However invisible you make the persistence mechanisms, that design
> > constraint is always going to exist, and will stick out like a sore thumb.

My impression from poking around the Prevayler site was that even
Oracle, known for its high bla bla bla, has exactly that same
constraint: *something* must go through a single point.  I gather it is
only the logging that must go through that point, although he seemed to
offer relief there, even, with an example of most of the work of logging
being farmed out to multiple loggers.  Further, even with logging done
on just one machine, apparently it can be done very rapidly.  The actual
serving did not need to be done by a single machine.  Anyway, that's
what I took away from my quick look.

I found the idea very interesting.  When I find the time (yeah, right),
I hope to play with it in an application I wrote and maintain for
medical accounts receivable.  The gist of a prevalence system, as I
understood it, would be:

 0. When closing down the server (or as often as you like during the
day), write out a snapshot of all your business objects.
 1. When starting the server, load all the business objects from the
last good snapshot.
 2. If there were any log entries after the last good snapshot,
re-execute the commands in those log entries.
 3. Perform the server functions, logging each state-changing command;
no need to log mere queries.

I envision a system that saves all snapshots and all log files forever,
and a system for a supervisor to review or search the logs, and for the
developer to step through the logs applying one command at a time.

This gives 
 1. a total audit trail (fraud deterrence, eliminates guess work as to
causes of errors)
 2. a way to debug any application problems (by getting a snapshot prior
to the problem and walking forward until the problem-causing command is
reached).


-- Frank