james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: JCR back-end
Date Sat, 05 May 2007 09:16:56 GMT

On 5/5/07, Ahmed Mohombe <amohombe@yahoo.com> wrote:
> 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?

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

One important aspect in achieving good performance is how you model
your content. The JCR model allows a couple of nice modelling options
not available in relational databases, most notably in JCR it is
possible to avoid many cases of relational joins. For example JCR
allows you to store a parsed list of message recipients as a
multivalued property of a message node, whereas the equivalent
relational model would require a separate table. I would in fact argue
that a JCR solution could easily achieve stellar performance for use
cases like "find all messages that contain these keywords and that
were sent to or from this domain within this timeframe".


Jukka Zitting

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

View raw message