Greetings! Thanks for taking the time to answer our questions. How is JDO different from Prevayler, found here: http://www.prevayler.com I've looked for a feature page, but the closest is this comment: "... is by far the fastest, simplest and most transparent business object persistence, ACID transaction, fault-tolerance, replication and load-balancing architecture we know..." and a little further on: "...With Prevalence we are finally free to create true object servers and use objects the way they were intended all along. ... able to use any algorithm, data-structure and query language we please. We are no longer constrained to the ones provided by database and application servers which must run on disk data-blocks. .. no longer have to license, install, configure and maintain a database and application server every single time we want to develop, demonstrate or deploy our systems for any of our clients. Give us a Java VM and we are good to go." Note that I'm not associated with them in anyway. I simply wanted to provide a synopsis of the product so that you could comment. [ June 18, 2003: Message edited by: John Takacs, D.P.M. ]
I don't know this technology, but it appears that it might be a persistence layer that could plug into a JDO front end to provide very fast in-memory persistence. Of course it has its own API, but many persistence layers can be plugged into JDO.
Originally posted by John Takacs, D.P.M.: Greetings! How is JDO different from Prevayler, found here: http://www.prevayler.com
I don't have time to do a thorough comparison of that product with JDO. But... It looks like this is an in-memory database, it says the entire database has to fit in memory. So they probably allow you to have all your objects in memory and provide efficient means for querying them. They could have a JDO implementation, but I did not see this mentioned. It sounds like their main point is that because the whole database is in memmory, they have architected a solution that is much faster. Direct memory access will always be faster than doing disk accesses and talking to separate server processes. In JDO, a cache is maintained in your JVM of objects accessed from the database. So for each access after the first access, you get the same object without accessing the disk. Some JDO implementations also provide their own caches that sit between your application cache and the database, to allow your transaction and others faster access to the data. As Craig pointed out yesterday, its all about the caching of data. You get client caching automatically when you use JDO, and an implementation may support additional levels of caching. So as you increase the level of in-memory caching of objects, you are moving along the continuum between a database on disk that you must constantly access and a database that fully resides in memory.
John Takacs, D.P.M.
Joined: Nov 15, 2000
Craig, David, Thanks for your help. I'm very happy with the answers you have provided. I will definitely purchase the book!
In fact, the Prevayler works with the prevalence of all object in memory, making logs and taking snapshots of the current system status, it uses only memory for persistence. If you download the Prevayler for the site, it comes whit some demos. In essence, it has not to do whit JDO. Regards,
Prevayler is exciting, but based on a fundamentally different paradigm than RDBMSs or even object databases. I doubt that it would be possible to front it with a JDO compatibility layer. I think everyone is still trying to figure out what the right domain for prevalence-based persistence is, how to use it, what its pros and cons are. It's not a "database" as such. It is a way to robustly persist your object model. Off the top of my head, the pros are
It's lightweight and simple. There is not the kind of "impedance mismatch" between object model and database that takes relatively complex technologies such as JDO to solve.
It can be incredibly fast: you simply operate upon a Java object model.
It is robust: if the application crashes you can reliably recover all operations right up to the crash.
The cons are
Although you can have a natural Java object model, this model must sit in an isolated box, and any interaction with the outside world has to go through the Prevayler API.
Everything must be held in memory. This is not as restrictive as it sounds; memory is cheap and plentiful these days.
It does not support ad-hoc queries. If you need a particular query, your object model has to provide the appropriate data structures for it.
It does not have much tool support. If you need to inspect or modify the state of the "database", you're on your own. My advice would be to implement toString() on all your objects so you can at least dump your object graph.
No matter what they say, there's no support for transactions as I understand the term, but because your database (read: object graph) operations can be arbitrarily complex and are not dependent on external I/O there is much less need for DBMS-like transactions anyway.
HTH, - Peter [ June 19, 2003: Message edited by: Peter den Haan ]