[Seaside] Prevayler

[Avi Bryant]

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...

Well, I'll tell you the issues I have with Prevayler, and maybe as you
look into it more you can tell me if or how they're resolved.

- Commands.  Correct me if I'm wrong, but every mutation made to a
persistent object has to be done by a Command.  I just don't see
this working in a Seaside (or WebObjects) application - I can't hook a
persistent object up directly to a form?

- Concurrency.  How is this handled?  For recovery, each mutation has to
be serializable in a well defined order, which means that presumably you
need to throw a lock around your whole PrevaylerSystem - not exactly fine
grained concurrency control.  I know, a lot of web apps use MySQL and its
table-level locking, but...

- Transactions.  Can you abort a transaction?  Rollback?  Doesn't seem
like it.

> With WebObjects, I find that transactions get lost - I
> find myself unable to call saveChanges() because I may be in the middle
> of a larger transaction, and I don't want to persist it's data to the
> database.

Isn't this what nested EditingContexts are for?  It sounds like you're
saying you'd rather have no transactions at all; couldn't you get the same
effect as Prevayler by calling saveChanges() after every mutation?

> And of course it's a very new idea - it may be possible to combine it
> with something like Aspect Oriented Programming to make it a truly
> transparent framework.

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.

Nor is AOP a panacea for transparent persistence, by the way.  To be
useful, it really needs to be able to add advice to individual instances,
not classes.  AOP systems for class-based languages tend not to be able to
do this (one exception is AspectR, which gets away with it because Ruby
has good facilities for adding behavior to individual objects).  So most
persistence systems based around AOP techniques (eg, the Java API to
GOODS) divide the world into persistent and non-persistent classes, which
is pretty non-transparent.

Hmm, I hope you're not offended that you post an implementation of
Prevayler and I immediately proceed to trash the concept.  I find object
persistence a very interesting problem, and so am intrigued by new
approaches, but in the case of Prevayler, I'm pretty sure the hype is
unwarranted.  I'd be happy to be proven wrong...

Cheers,
Avi