Hi serge Jackrabbit is designed for storing the entire item state as a single unit. Trying to preserve the types or force referential integrity at database level would need to perform too many tasks at the PM level which inevitably will hit performance. That's the strength and weakness of the implementation I uploaded to JIRA, it preserves the type and forces referential integrity but it uses too many queries for any operation, either for reading or writing.
This kind of approach needs change aware objects for every collection contained in the ItemState. Without this persisting a simple change like adding a single child node might need hundreds of queries to the database, which would be unbearably slow for any kind of app. > This brings me to beg the question : what is the recommended setup to > use Jackrabbit in a clustering environment ? AFAIR the conversation was closed without many clarifications about the complexity of the task, maybe someone can shed light on this issue to help the users to evaluate whether they can handle to code their own implementations, which hopefully might be contributed and eventually added to the project ;). > - the JCR-RMI implementation should be able to talk to more than one node > - adding another type of implementation such as JCR-RMI that would work > with a cluster. I can't follow you here. AFAIK jcr-rmi can already be used for clustering. If the benchmarking initiative evolves you will be able to test the performance of this strategy to check whether it fits your needs. kind regards, edgar
