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... > > > HTH > >
