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" :)
cheers,
Serge...
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 :
http://www.theserverside.com/news/thread.tss?thread_id=33341
commons transaction might also be useful:
http://jakarta.apache.org/commons/transaction/file/index.html
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
Thanks
Philippe
