jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrei Latyshau" <andrei.latys...@gmail.com>
Subject Re: Use JackRabbit CMS for storing Business Objects
Date Fri, 22 Aug 2008 06:22:24 GMT
I still not see that JackRabbit can be used for storing usual entities.
There are my comments below.

is your question saying that you are afraid that it might be only useful for
> storing documents?
Yes, because the performance of JackRabbit is very very low. I understand
that probably we have some issues in environment setup, therefore I ask.. We
use Jackrabbit to dynamically create node types and mix-ins on runtime, we
use nodes with 10-20 mix-ins, each mix-in contains one property, we have
node with 100 000-1 000 000 children, each containing unique set of mix-ins.
We need to make complex queries on such hierarchy. Maybe we can organize our
data in such hierarchy when we will have no such amounts of children, but
our tests showed that even on small amounts of data JackRabbit is killer of
performance (seconds for simplest queries, minutes for usual queries). Our
performance criteria for all screens are <1sec, by that there can be 100
users working in parallel.
We need some expert who can suggest the correct way of usage of JackRabbit
for objects with custom fields (searchable).

> if so, then no. It's useful for all kind of data. Re logic and semantic
> it's probably more a question how to layer this.
> Our approach is normally something like
> Controller
>  |
> Custom Data Model/API
> |
> Custom Data Implementation

Actually we need to make decision now for this layer of abstraction, as we
are going to implement it. The object mapping on CMS and on relational data
base is very different. There we have different concepts. And we are not
going to implement this mapping twice. Currently we decided to map our
objects on JPA, but also want to get an expert opinion - we have no
expirience with JackRabbit.

> |
> JCR or some other Data Abstraction API
> |
> Jackrabbit (as JCR implementation)
> |
> some data repository specific persistence manager
> |
> actual data repository
> with this approach one has great flexibility and doesn't have to be afraid
> of possible peformance/scalability issues, because
> one can rather easily switch the implementations

As we see, when we decide using JackRabbit, then any rotation of layer below
"Data Implementation" will not help...


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message