Prevayler is the free-software Prevalence layer for Java. It is not a database, but can be used as a replacement for a database in many circumstances. It uses object serialization to store all the modifications to your data in a sequential form.

Features

• Automatic rollback for transactions that fail (throw RuntimeException).
• XML snapshots.
• Transient Prevayler support for automated testing and demos.
• Prevayler.close() implemented.

Read more at:

Prevayler 2.0 is out

1 minute introduction to Prevayler

Prevayler's home page

Prevayler is pretty snappy to develop with. I'm glad it's on the Spring roadmap ( here and here ) so it'll become another easily swappable persistence option.

Perhaps I have too much of a relational DB mindset, but rollback which you paid for when a TX rolled back instead of every time would be nice.

Rather than trying each transaction on a copy of the data, and then applying it to the 'real thing' if it works, why not apply it directly to the 'real thing', and throw away and re-load it if the TX fails? A successful TX would be just as fast as if rollback wasn't enabled. As long as rollbacks are rare relative to successful transactions this would be a big performance win, and would make it much easier to use prevayler with existing code.

Obviously I haven't thought about this nearly as hard or long as the prevayler team have, but I don't see that this approach is any less reliable...

hey tom!

it works like this:
prevayler makes the copy of the system only before the first transaction and after a failing transaction.

pseudocode:

if (foodtaster == null)
 foodtaster = copyKing();
if (execute action on foodtaster fails)
 foodtaster = null;
else
 execute action on king

regards
 chris

prevayler makes the copy of the system only before the first transaction and after a failing transaction.
if (foodtaster == null)
  foodtaster = copyKing();
if (execute action on foodtaster fails)
  foodtaster = null;
else
  execute action on king

...but you execute twice the successfull transactions. Or so it seems in your pseudocode. And that's the price to pay when you want Prevayler to do the rollback for you. Still, it seems possible to not use this automatic rollback and implement it by yourself with command/memento design patterns which would certainly be a lot more efficient but some more work.

yeah, transactions are executed twice. btut the execution of the transaction is not an expensive opration. serializing it is expensive and happens only once. and copying the system is also expensive but happens only after failing transactions

regards
 chris
(using prevayler in production for over a year)

yeah, transactions are executed twice. but the execution of the transaction is not an expensive opration. serializing it is expensive and happens only once.

Good point. Thanks for the experience from the field.

yeah, transactions are executed twice. btut the execution of the transaction is not an expensive opration.

How do you know? I mean, as I understood it, I can put as much business code as I like inside a transaction, so it might be of arbitrary expensiveness?

Please enlighten me,
Lars

yeah, transactions are executed twice. btut the execution of the transaction is not an expensive opration.

How do you know? I mean, as I understood it, I can put as much business code as I like inside a transaction, so it might be of arbitrary expensiveness?Please enlighten me,Lars

In my projects i found that transaction execution time is really very fast. i dont say there are no use cases where this is not the case. there are some things you'd better not do inside a transaction, like writing big files, or accessing 3rd party systems. I found it better to make a short prevayler transaction at the end of such long running stuff, then to make everything in one big transactions. one more reason to keep transactions short is that prevayler only executes one transaction at a time.

hth
 chris

but you execute twice the successfull transactions. ... And that's the price to pay when you want Prevayler to do the rollback for you.

See http://www.prevayler.org/wiki.jsp?edit=InstantaneousTransactions

hey tom!it works like this:prevayler makes the copy of the system only before the first transaction and after a failing transaction.
pseudocode:
if (foodtaster == null)
 foodtaster = copyKing();
if (execute action on foodtaster fails)
 foodtaster = null;
else
  execute action on king
regards chris

Chris,

Thanks, I understand better now.

I'm suggesting:

if (king == null)
  king = loadKingAndRollForward(); // that is, restore from the persistent store
if (execute action on king fails)
  king = null;

So you don't have to execute an action twice, and you don't use as much memory, but you do need to do a reload instead of a copy when a transaction fails.

I imagine that reloading is more expensive than copying?

restore from the persistent storeif (execute action on king fails)  king = null; So you don't have to execute an action twice, and you don't use as much memory,

The thing is queries run in parallel with transaction execution so, in your suggestion, the queries would see the effects of a broken transaction.

Prevayler never replaces the king system. If you were to replace the king, you would have to add a level of indirection for queries, and nobody wants that.

Obviously I haven't thought about this nearly as hard or long as the prevayler team have, but I don't see that this approach is any less reliable...

I think your idea makes sense. The problem is probably that you cannot implement a more efficient automatic rollback system like the one you describe without imposing a new contract (read "interface") on the classes of your persistant objects.

I read the intro to Prevayler and saw this:

 Simpler and faster development time.

If the database has to be loaded at startup, won't it take quite some time with a reasonably large database? I mean, the startup will take longer time with a larger database, even with snapshots.

If the startup takes time, doesn't that impact development time negatively?

the loading of the database happens at runtime.
while creating / implementing the application (development time) only little amounts of data are needed for testing (with the exception of testing the behaviour under load) and so only little data has to be loaded.
=> no negative influence on development time

the mentioned positive effect on development time probably refers to the fact
-that with prevayler it's not necessary work with big and complicated database systems
-and that it's not necessary to design an additional database schema (class diagram = data base schema)

the loading of the database happens at runtime.while creating / implementing the application (development time) only little amounts of data are needed for testing (with the exception of testing the behaviour under load) and so only little data has to be loaded.=> no negative influence on development time

Well, in that case I guess it depends on how you do things. I usually work with a real database from some customer even during development. Gives me a better "feel" for how it'll work IRL.

the mentioned positive effect on development time probably refers to the fact -that with prevayler it's not necessary work with big and complicated database systems -and that it's not necessary to design an additional database schema (class diagram = data base schema)

Aha, so for someone like me who uses a Java object database (Jisp/JDBM) there's no difference then. The blurb should probably qualify the "faster" part then, with just what it is supposed to be faster than.

Databases have the same log files for recovery and use memory cache for performance. As I understand databases are implemented for reason and do not have any problems, is it some reason to replace database with log file and memory storage ?

Databases have the same log files for recovery and use memory cache for performance. As I understand databases are implemented for reason and do not have any problems, is it some reason to replace database with log file and memory storage ?

Before RDBMS, we had flat files and mainframes. There was nothing wrong with flat files and mainframes either, was there?

Judge the project on its merits .. don't assume that everything of value has already been done. ;-)

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

Yes, this looks like as a step back to flat files, but I see nothing wrong in flat files too.

Iterating all the elements in memory to search for name.equals("bob") is not going scale for enterprise apps. OGNL and JXPath can index the elements in memory, and provide fast queries once the indexes are created, but this is a very different proposition from a database that keeps indexes on disk and actually supports queries. I don't want to pan prevayler, because I think it is a great solution for small applications with small datasets, especially when used with JXPath. However, many people get confused on their first look and think it's a viable alternative to a database. Prevalyler is not a database.

<quote>
Iterating all the elements in memory to search for name.equals("bob") is not going scale for enterprise apps.
</quote>

Why would you want to iterate? Why not just use a HashMap? That's essentially what an index is anyhow. Anyhow, I would use this more for an enterprise app. I have full confidence in my programming ability, and don't mind squeezing out a few ORDERS OF MAGNITUDE of performance for the rather small sacrifice of SQL.

eg. in an enterprise system, I would look at trying to get a few computers with 16GB RAM each, rather than going and spending heaps on a database.

And, I would manage the prevaylers myself (load and unload if necessary). Most data would be summarised.

All of the "problems" of prevayler can be worked around by competent programmers who are able to think inside a new box.

Cheers

Stephen