is the free-software prevalence layer for Java.
for native Java business objects.
-3 to 4 OrdersOfMagnitudeFaster
than databases via JDBC.
- Simplicity, Transparency and Speed
- How does this site work?
From the Java2 Standard Edition 1.4 datasheet:
"64-bit support provides Java technology developers with near limitless amounts of memory for high-performance, high-scalability
computing. While previous J2SE releases were limited to addressing 4 gigabytes of RAM, version 1.4 allows Java applications to access hundreds of gigabytes
of RAM. [On 64bit architectures] This enables developers to drive more applications and very large datasets into memory, and avoids the performance overhead of reading data in from a disk or from a database."
"After doing lots of tests we are now using Prevayler
in one of our production systems. And Wow! this baby flies!
I'm very pleased with the simplicity of design and the performance of Prevayler
We've been using Oracle
and a persistence layer in our first project and it was _very_ painfull. Started the second marketplace with the same persistence layer and I got so fed up with it that I decided to change to Prevayler
in the middle of the project. Just like that. And I love it!"
(Head of Technology), http://www.otop.de - ^e-Health-Care Marketplace
Want to know what's new on the Wiki? Check RecentChanges
"Although I'm not using the prevayler code, I've come up with a very similar approach during design and development of a simple medical hardware application. The requirement was to keep a database of patient data consisting of personal data, test sessions and test results.
It all ended up living in the RAM. Our average customer's office worth of data for this application fits comfortably (in text file form) on a 1.4MB diskette, so it was more than obvious not to have anything to do with files -- the whole database is read from the (hand-modifiable, if need be) text file on startup, and is then saved as a whole whenever the patient file is closed. A command log is in the works, and -- given the database's almost negligible size -- the command log will be the only and ultimate way of storing the database -- yup, without any kind of persistent snapshot.
Internally, I ended up implementing quite a few concepts of object prevalence. Right now I'm cleaning up the client code/business command separation.
Although I've got to know the prevayler project only as of today, I've managed to implement almost the same thing. It took me almost half a year of deep thinking about how to do that, I admit. Nicely enough, the database was the last thing to be done in that partiular app. Given enough thought, the prevalent objects idea -- to me -- seems the only clean-cut way to manage data without having a dozen layers between your client, your business logic, and your data. It's a 13k line C++ application (using Qt) that manages its data in an ACID
clean way, talks to the hardware (about 35% of the code is the hardware interfacing code), and provides a user interface for all that. Doing it 'the obvious way' would require at least bundling a hefty embedded database library, or using MySQL
for simplicity's sake. After some conservative estimates I come to the conclusion that object persistence interfacing to an SQL data storage thing (RDBMS
, whatever) would take more time to cleanly implement and debug, than just going with the object prevalence. I even went as far to give GigaBase a test run for about two week. Even though it was much easier to use than your typical parsed query based system, it still looked very hackish.
All in all, it's a neat concept, it has allowed me to keep the code clean and extremely simple (even in C++ with Qt), and is something that should be taught in computer science database courses, on par with classic RDBMS
theory and practice. I admit that, in fact, it may only be the lack of formal CS education on my part that gave me a clean-enough horizon to actually live happily (and without prejudice) with object prevalence."
, a freelance developer
I think it was a mistake to not have the wiki be prevalent during the Slashdot inundation a few days ago. Everybody on Slashdot was making fun of how quickly your own server died.
--Carl Youngblood, computer programmer
Yep, quite unfortunate. Everyone assumed that the site was being run by a prevalence engine. Which was an incorrect assumption to make.
Oh well. a lot of people on slashdot are still attached to their database.
64 bit cpu's and hopefully a serious decrease in ram costs will see most systems using some sort of prevalence engine