On Wed, 16 Mar 2005 20:44:20 -0300, Edgar Poce <[EMAIL PROTECTED]> wrote:LocalFileSystem is really slow in windows boxes, you should use CQFS instead. With LocalFileSystem or XmlPersistenceManager if the jvm process is killed the repository might turn inconsistent. Besides, none supports transactions.
i would argue that ObjectPersistenceManager with CQFS is quite stable and reasonably efficient. on the other hand, as i pointed out in a couple of
earlier threads, i don't think that a persistence manager that stores
the item states in a complex schema is the right way to go. i'd say keep
it simple, e.g. the ObjectPersistenceManager stores the item states as a raw stream of bytes. if you think further, a b-tree based database (like berkeley db) would IMO be an ideal candidate to store such raw
byte streams.
Edgar and Stefan, thank you for your replies. You seem to fade out that magnolia is an open source project and CQFS is not. So, CQFS might be an option for a mid-size project that can afford to buy CQFS but it is no option to bundle CQFS with magnolia in general.
Our first tests with the HibernatePersistenceManager have been satisfying with respect to performance, though not overwhelming when compared to CQFS. I've read about the current shortcomings of HibernatePersistenceManager and OJBPersistenceManager in http://issues.apache.org/jira/browse/JCR-63 and I realize that the existing codebase is just a start.
Stefan, I understand your argument about persisting object state into a complex schema and it makes sense to me. What would be your estimate of working days to implement such a BTreePersistenceManager for a senior java developer? If we counted correctly there are 12 methods in the AbstractPersistenceManager that would have to be implemented.
Another way could be to reuse the existing ObjectPersitenceManager together with a special FileSystem implementation. This FileSystem (perhaps DatabaseFileSystem) would handle the storage of the serialized JCR objects in a simple DB schema representimg a filesystem. I assume that this solution would be quite fast (depending on BLOB handling implementation of the DB Driver) because you have relatively few tables (~2, paths+data and tree structure) and gain a lot of reading speed by using indexes.
Now, this has become a different thread and if you or anybody else still has input for my starting questions, please, you're very welcome.
-- Cheers, Michael
