Prevayler

[Rikard Qvarforth]

ohhh i like it, i like it alot

(dident now where to put this post so it went here)

[Cindy Glass]

OK, wanna tell us why you like it so much, and let others in on the wonders of it.

[Rikard Qvarforth]

no more sql no more connections no more ... . and best of all its all java objects. Well i have not worked with a object db before but working with prevayler is a delight
forgot the link http://www.prevayler.org/wiki.jsp
[ January 22, 2004: Message edited by: Rikard Qvarforth ]

[Jim Yingst]

This sounds like a good post for our Object Relational Mapping forum, so I'm moving it there...

[Frank Carver]

Hmm. I hope we don't get a bunch of "it's not really ORM, is it".
Although Prevayler (and the idea of "object prevalence" in general) can solve some of the same problems as using a database, it's not really the same thing at all.
The idea is essentially that instead of writing data to a database, all data is kept in memory, for immediate use. This is not as mad as it sounds, as an enormous proprtion of the worlds databases woould probably easily fit in a few tens or hundreds of megs of RAM. The main problem is that RAM is volatile. It's easy for it to get turned off, or for the process managing it to crash or be stopped. To solve this, the idea of prevalence is to occasionally "snapshot" the contents of memory, and keep a log (on disk, or whetever) of all the actions that happen in the application. If something goes wrong, just load the most recent "snapshot" and replay all the actions that happened since.
If your application is built that way (and a surprising number are) then this approach can work really well. Instead of managing complex databases and cache algorithms, and moving data back and forth all the time, just store a few bytes indicating something like "add('Frank Carver', 123.4)" for each thing that happens.
Conceptually it's a bit like the idea of storing the source code changes for a development project in a version control system. Using a database would be like storing all the compiled executables, and fetching them from a remote system every time you need to run a bit of code.
I like it a lot, and it makes managing the storage and reconstruction of complex Object graphs far more transparent than any ORM system I've yet seen.

[Lasse Koskela]

Yes, prevalence is an interesting approach to persisting business objects. I have a couple of worries, though (some of which might be found from the FAQ, I guess):
1) How to make sure that the box doesn't go out of RAM? There's really no way of calculating the memory usage of an application accurately, which might lead to problems.
2) How about reporting? The relational model is terrific for reporting purposes, and reporting is a critical business function. I strongly feel that Prevayler & Co. need to enable reporting/browsing the "database" somehow.

[Ilja Preuss]

Originally posted by Lasse Koskela:
1) How to make sure that the box doesn't go out of RAM? There's really no way of calculating the memory usage of an application accurately, which might lead to problems.

How do you make sure that your database doesn't go out of disk space?

[Lasse Koskela]

Originally posted by Ilja Preuss:
How do you make sure that your database doesn't go out of disk space?

Yes, we monitor the disk space, hotswap disks, move to tapes, etc., but I don't see those "tools" available for Prevayler, for example? Besides, we can buy server disk space with a lot less than server memory so there's room to "play it safe" with HDs.

[Frank Carver]

2) How about reporting? The relational model is terrific for reporting purposes, and reporting is a critical business function. I strongly feel that Prevayler & Co. need to enable reporting/browsing the "database" somehow.
I still feel there may be a little misunderstanding going on here. There simply is no "database", of any sort. There's just the application, built out of a bunch of objects, and a few scattered notes about how to reconstruct its state if there is a crash.
If you want to write a report you have the full power of a real OO programming language (or, indeed, any scripting language you wish to layer on top of it). For example, to list all the transactions associated with a particular branch might be something as simple as:

public Iterator listBranchTransactions(String branchName)
{
  Branch branch = organization.getBranch(branchName);
  return branch.getTransactionList().iterator();
}

You have to continually remind yourself that it's all in memory so (1) it's typically at least an order of magnitude faster than any database access, and (2) you are free to reference any object from any other object, and you have powerful concepts like List, Set, and Map, etc. etc.
There are some downsides to prevalence, of course.
Audit trails and historical data can be tricky to manage. We are not yet at the stage where there is really enough RAM to hold all of everything, for ever. In an OO application, it's easy to delete stuff, but if an audit trail is required, then data never really gets deleted, just marked as archived. A prevalent system may have to delegate to a more traditional backing store for this sort of use.
The issue I guess you were getting at above is that there is no standard interface to plug in external tools (such as ad-hoc reporting tools). Each application is different, lacking a standard such as SQL which is (largely) portable across vendor and client implementations.
There are several interesting possibilities for this, though. It would be relatively easy for an application to make its internal state available through JNDI, or RSS, or JavaSpaces, or maybe JMX or the debugging API might prove suitable. What these (and no doubt many others) have in common is that they are rich OO interfaces rather than the tables-of-primitives model assumed by SQL.
Once some sort of standard (let's call it the AppStatus API) is in place, you could (if you wish) provide a SQL-to-AppStatus bridge to allow access by legacy applications that assume a database.
Hmm. I wonder if anyone is working on this yet?

[Frank Carver]

Yes, we monitor the disk space, hotswap disks, move to tapes, etc., but I don't see those "tools" available for Prevayler
Does your operating system not provide tools to monitor the memory used by running processes? I can usually see how things are going using the likes of "top" or even the Windows Task Manager. In some ways RAM usage is already cleverer than disk usage. I've not worked on any system which handles transferring excess data from disk to tape anything like as smoothly and transparently as the "swap" mechanism for paging unused memory data to disk.
Unfortunately, the "fly in the ointment" at the moment is that the current crop of JVMs are not especially swap-friendly. Memory map layouts are optimised for speed of access and simplicity of garbage collection rather than clumping of related data for efficient swapping.
Besides, we can buy server disk space with a lot less than server memory so there's room to "play it safe" with HDs
This is true, but both disk and RAM sizes are growing at a phenomenal rate, and the imminent adoption of 64-bit addressing will allow low cost systems to smash through the current 4GB RAM limit.
And many data stores seem to take up a lot more disk space that would seem to be needed by a simplistic data analysis. take JavaRanch, for example. We currently seem to have something less than 500,000 messages. I can guess that the average message size is less than 1k - sure, many are more than 1k, but the great majority are much, much less. So the raw data requirement for JavaRanch is of the order of 500,000,000 bytes, or 500MB. Even allowing for a doubling in size, that's still only around 1GB, which would easily fit in memory on a reasonable modern server.
Think how fast JavaRanch would be if it was all in memory!

[Lasse Koskela]

With the reporting remark, I did mean that there's nothing to query against... For some reason, I hadn't thought of providing an API through the application, however.
The actual source of my concern regarding the memory-usage was that I've been lately working with systems that produce approximately 1 kilobytes of commercial log information (audit trail) per second, parts of which must be stored for 10 years. Now, I can't keep all that in memory forever so it must be written to disk at some point. That's where I was coming from. It would be nice to hear about some real-world implementations.

Think how fast JavaRanch would be if it was all in memory!

In fact, I worked on and off for 2 years around a system that had pretty much everything in memory after a bit of warm-up. I'm not sure how many gigabytes it took but I would guess approximately 1GB in each box. It still wasn't too fast (although the biggest contributor to the slowness was the somewhat bulky ecommerce engine we had to put up with)
By the way, I've heard rumors that MySQL's upcoming clustered database is using prevalence type-of all-in-memory approach... It's going to be interesting to see how much punch they've gotten out of it.

[Renat Zubairov]

Hi.
I'm just curious, how often this database is used in production. I mean how many companies use it to earn money. I can admit that for small experemental projects it's very nice looking (I didn't try it yet, but from documentation) and probably fast enought, but what about such things like replication, availability, scalability.
Especially about scalability, I have read this
http://www.prevayler.org/wiki.jsp?topic=ScalabilityTestResults
And can see general mistake people does . We all know that there two types of scalability: Vertical and Horizontal. And on the page I can see discussion only about vertical one. But as we all know (again) drawback of vertical scalability is - decrease of availability and I can't see any possible solution there.
Br.
Renat