james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ahmed Mohombe <amoho...@yahoo.com>
Subject Re: JCR back-end
Date Sat, 05 May 2007 09:44:06 GMT
>> The problem I see however is that most big DMSes *don't* use JCR
>> because it's slow when it comes to such big amount of documents
>> (it's nice nice in theory but not in practice).
> I'm not sure I understand your point. Just like with JDBC, performance
> is mostly a question of the implementation not the API. There aren't
> any inherent performance or scalability bottlenecks in the JCR API, so
> perhaps you are referring to the Jackrabbit implementation?
The API/Specification is just the theory, not what really powers an application.
Of course it's the implementation. Unfortunately not just jackrabbit but all
available JCR solutions so far are slow from this perspective. This is of course not the fault
of the API/Specification (only if requires things that can't have fast implementation :) ).

>> My experience is that if a (JCR) solution for mail archive wants to be 
>> usable
>> to the potential users (much more than is JCR to CMSes and DMSes)
>> performance should be the first and most important feature.
> I don't quite agree that performance is the "first and most important"
> feature, but it certainly
> is an important aspect. While there are many things to be done for
> better Jackrabbit performance (and we're working on that), I already
> find Jackrabbit quite fast for many typical operations.
I don't expect you to agree :), but if you would feed a JCR based DMS with a few
GB of documents I'm convinced you would see what I mean :).

> One important aspect in achieving good performance is how you model
> your content. 
In most cases this is not really an option for the developers, as the required "metadata"
documents is already to a high degree predefined by the customer.

This is not a bash against JCR, but just a few cents from my experience.
In a lot of projects, JCR got a fair chance, but failed, mostly for performance reasons (the

developers loved the API).
After several optimization trials, the cheapest solution was always to get a few very expensive
specialists and have the problem solved the "relational way" :).


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message