jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Aemisegger <develo...@pagnolia.ch>
Subject Re: Best practice for Asset management
Date Thu, 17 Mar 2005 13:56:11 GMT
Stefan Guggisberg wrote:
> On Wed, 16 Mar 2005 20:44:20 -0300, Edgar Poce <edgarpoce@gmail.com> 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.


View raw message