jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Best practice for Asset management
Date Thu, 17 Mar 2005 09:31:04 GMT
hi edgar, 

On Wed, 16 Mar 2005 20:44:20 -0300, Edgar Poce <edgarpoce@gmail.com> wrote:
> > I'm sorry for the fuzzyness of my questions, but I still lack experience
> > with JCR. I guess the performance related questions depend heavily on
> > the combination used for FileSystem and PersistenceManager
> > implementations, and of course OS, and .... Still, can you share
> > experience in this area? I'm particularly interested in experience with
> > plain jackrabbit configuration (LocalFileSystem & XmlPersistenceManager)
> > and ORM configuration (HibernatePersistenceManager), ceteris paribus.
> >
> 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 moved to orm persistence for these reasons, but for now, none of the
> implementations are production ready. If you want to give it a try, I

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.

> suggest you to start with the patched OJB PM rather than the hibernate
> PM. See JCR-63 in JIRA.
> btw, I'm thinking of making a console tool that checks the persistence
> manager consistency. The tool would tell the number of unexistent
> referenced nodes, and with -repair option it will prompt to delete
> references to unexistent children. I guess it's not the best solution
> but at least it could make the repository back to life. No other
> inconsistency come to my mind now but I guess we could add more sanity
> checks.

cool! if you would like to contribute such a command line tool i'd be 
very interested.


> > Cheers,
> > Michael
> >
> >
> regards
> edgar

View raw message