jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Nuescheler" <da...@day.com>
Subject Re: JCR Drawback Thoughts
Date Mon, 30 Jul 2007 07:43:30 GMT
Hi Philip,

Thanks for your feedback.

> I have been experiencing performance issues with my application.  These problems
> have caused me to reflect on how my application is using JCR vs. the custom object model
> that it was using before.  Based upon my thoughts, I think that I will have to migrate
> from JCR, back to a custom schema.
I think it is important to understand that performance issues are
issues (in the vast majority of the cases) and not specification issues.

> Much of my application consists of 1) Search 2) display search results 3) view search
> If I perform a search, and I get a hit on a PDF document,
> I do not need to load the pdf byte array (jcr:data) into the node in order to display
> my search results.
I agree. What makes you think that thats what happens?
The spec certainly allows for "lazy loading" of property values and
jackrabbit (mostly)
makes use of that for binary properties.

Sometimes a slow implementation of a Value.getLength() [which is used on typical
typical results pages, displaying a filesize] may trigger the loading
of the binary
But again this is an implementation (JR) issue, not a spec issue.

I think it is save to say that since your use case is a very typical one for a
content repository, it should be blazingly fast in JR.

> That is the crux of my performance issue.  When I get 400 search results
> in a JCR search, I need to only display the only the first 10, and only utilize
> a few of the properties.   I don't need to load all the properties for all 400
> nodes.  I should note that while there is a next/skip on the NodeIterator, I
> need to evaluate a least some of the properties for each of the 400 nodes
> since some of the Nodes are duplicate results based upon tagging...
>From a JCR perspective it is important to know that you can specify the
properties that you are interested in your query.

for example ...

SELECT jcr:lastModified, jcr:path FROM nt:resource WHERE CONTAINS(*, 'jsr 170')

or equivalent in xpath ...

//element(*, nt:resource)[jcr:contains(., 'jsr

... so you will not have to fetch the nodes,
but can have direct access to the property values through .getRows() on
the QueryResult.

> So summarize my thought in a different way, if the JCR spec could
> be amended to support the dynamic selection of Node properties to
> be initialized in a NodeIterator, this would provide  my application the
> flexibility to perform as required.
For queries that should already already taken care of (see above).
Please keep in mind that the specification leaves it up to the implementation
when to load the property values.

As mentioned: I think your use case is very typical for a content
repository and I am convinced that we can help you to get to the performance
you need for your application either through configuration or performance
optimizations in the jackrabbit implementation.


View raw message