jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel May <marcel....@consol.de>
Subject Re: Efficient way of loading multiple properties of a node?
Date Tue, 24 Oct 2006 11:57:27 GMT
Jukka Zitting wrote:
> Hi,
> On 10/24/06, Alex Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
>> You are right Julian, but the spec doesn't say anything about batch
>> propery fetching; so Steffan is right: it is an implementation detail.
>> And if the implementation proves itself to go over the wire to fetch
>> each property then this would be considered an important design bug in
>> that implementation.
> I'd call it a feature rather than a bug since there are cases where
> aggressive caching of property values is not a good idea, for example
> if you're just traversing the node tree, then prefetching the property
> values will just slow things down. In any case it's an important
> consideration that I certainly wouldn't discard as an implementation
> detail. In fact I'd call the property access performance a major
> non-functional feature, that we might want to specify some benchmarks
> for to guide application developers on what to expect.
I agree on this that when a node is fetched, the properties should not
automatically be fetched by default, too. Though it would be nice thing
for the future JCR spec to cover eager subtree loading by API.

I rather thought about aggressive loading for the bulk operations, when
all nodes or properties are iterated. I'd like the Node.getProperties() or
Node.getProperties("somePattern") to fetch the properties not through the
LazyItemIterator which always preloads the next item but in one bulk
call to
the backend (for my case, a database). The same applies to Node.getNodes()
and Node.getNodes("somePattern").

So, these methods
- Node.getProperties()
- Node.getProperties("somePattern")
- Node.getNodes()
- Node.getNodes("somePattern")
would be good candidates for aggressive/eager loading, right?

This kind of 'agressive/eager' implementation detail could also be
so it's up to the specific scenario if eager or lazy loading is
done... similiar what many
other persistence frameworks provide - eg Hibernate, EJB Entities/JPA etc.
At the moment the behaviour is like the old EJB Entity 'n+1' finder
lazy loading thing -
one backend call for getting the ids of all the items, and n load
calls during iteration over the result.

My real life use case is fetching a whole node including its
properties (~15), but bulk fetching the properties would already help
alot since this would significantly reduce the backend (DB) calls. And
accessing all child nodes of a node in one backend access.

BTW, I'm willing to help out for this as this part is essential for my
company and the current project using Jackrabbit JCR.
Like by providing a benchmark examples (with Jamon monitors), patches etc.

> PS. There actually is one way to achieve batch property access in JCR,
> namely the XML export feature. Create a custom ContentHandler that
> simpy records the Attributes instance and ignores all other SAX event
> information. Note that the received XML attributes may be encoded as
> described in JSR 170, but for many use cases this is not a problem.
> It's a bit of a hack, but if you're limited by a network layer like
> JCR-RMI that needs to do a network roundtrip for each property access,
> it might be the best option there is...
> BR,
> Jukka Zitting
I'll look at this. Interesting workaround, though a bit of hack I
guess. Quite creative :-)

Thx guys for all your attention about this!


Marcel May
ConSol* Software GmbH
Tel: +49 89 45841-155

View raw message