Hi Frédéric, - Jackrabbit doesn't like same name siblings, so it would be better
to give nodes specific names;
The problem with same name siblings is two-fold: One is the implementation inside Jackrabbit and one is the specification. For example, consider a node /A with 5 children named B. You would access the first as /A/B[0] the second as /A/B[1] and so forth. If you now decide to delete the second one (B[1]) the indices of all same name siblings whose index is larger than 1 will change. So B[2] becomes B[1], B[3] becomes B[2] and B[4] becomes B[3]. IMHO this is problematic and this is why I never use same name siblings. AFAIK, inside Jackrabbit same name sibblings result in an additional indirection to handle the list of nodes with the same name. - Jackrabbit doesn't like too many child nodes under on same nodes
(ie. 1000 or more child nodes for one parent node)
This is purely an issue of the current implementation of node states. But, honestly, I do not think the critical limit is already at 1000 child nodes, this number should be much higher - of course not considering same name siblings. But it is true the more child nodes you have on a single parent node, the more performance will suffer and the more memory consuming Jackrabbit will be. Your main issue is using same name siblings. (Did I already say, I don't like them ? :-) ) But I don't think my repository structure is unique. While the JCR API is intended to also support such flat hierarchies, it is really the support for higher level hierarchies, which makes the API unique. And this is also at the bottom of the Jackrabbit implementation: Flat hierarchies have only been a side goal of the design. It seems that searching one this kind of architecture takes ages, I made a
search yesterday that I stopped after 25 minutes. /jcr:root/lgw:root/lgw:contracts/lgw:contract/jcr:deref(@lgw:internalContractor, 'lgw:contractorType')[EMAIL PROTECTED]:companyName='Legisway']
I agree, that 25 minutes is not acceptable. I cannot tell for sure, what the problem here is, but I assume it is all linked together: flat hierarchy and a query which seems to be expensive to handle - I could assume that the jcr:deref function might have quite a high cost. I think is quite common)? I tend to think, that not everything which is "quite common" is also "good" by definition. Don't get me wrong here, I do not want to say, your architecture is bad. But it seems that the architecture does not cope well with the current implementation of Jackrabbit. Regards Felix
