jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Huber <shub...@jahia.com>
Subject Re: Performance issues of using "object" repository rather than "orm"
Date Mon, 23 May 2005 13:04:43 GMT

Sorry for the late reply, I was out of the country these last days and I 
couldn't join in.

As the person that originally contributed the orm implementation, my 
rationale was the following :

- I needed an PM I could cluster easily, and I thought it's easier to 
cluster DBs than filesystems.
- I needed it to have decent performance, preferably by using in-mem 
caches of data so we avoid going to the DB all the time.
- I wanted to avoid having to rewrite everything from scratch, by using 
proven DB persistence frameworks.

So I chose to learn Jackrabbit by doing ORM implementations. I started 
with the Hibernate implementation, which was a little tricky to do. And 
then I tried to make the implementation ORM-agnostic by adding the OJB 
implementation. Unfortunately I then realized that these 2 are different 
enough to cause problems, which is the reason of the complexity of the 
current codebase.

Now I do agree with Stefan that if you are looking at pure performance, 
file-based PM implementations will be faster. Again, the PM interface is 
all about offering choice, not about "there can only be one" :)


Philippe Girolami wrote:

>>do you have the url at hand?
>Oups, my bad. It's not transactional : just a "clean" way of accessing the
>file system from EJBs :
>>commons transaction might also be useful:
>Yes ! Anyone know the performance penalty ? Is it write only ?
>>in general this is correct. the query implementation does not rely on
>>the persistence manager in use. by design, the query handler is not able
>>to see the persistence manager implementation. though it would be
>>technically possible to write a query handler that is aware of a
>>database content store, and translate the jcr queries into native
>>database queries.
>>what clever SQL queries do you have in mind?
>Obtaining nodes directly by querying one of their attributes (not UUID),
>that must be very easy to do via SQL for simple queries

View raw message