jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Rauschenbach <David.Rauschenb...@SYNCHRONICA.COM>
Subject Re: RMI vs. JNDI
Date Wed, 18 Jun 2008 08:32:05 GMT
JavaMail has a nice Folder.fetch(FetchProfile) method that lets the caller share intentions
on what kind of data access is going to happen.

Folder folder = store.getFolder("myNode");
Message[] messages = folder.getMessages(); // return light-weight references to "node"s
FetchProfile fp = new FetchProfile();
fp.add(FetchProfile.Item.CONTENT_INFO);
Fp.add(FetchProfile.Item.ENVELOPE);
Folder.fetch(messages, fp); // pre-populate parts of each message with FetchProfile, so only
the remainder lazy-loads

This type of a "fetch" (pre-fetch) method is the perfect place to do a propfind type of operation.
A JCR equivalent would allow a caller to specify things like depth, and nodetypes of interest,
so that they can all be grabbed via a single traversal of SPI, and then only the remainder
of data accesses would cause lazy-loading, like the heavyweight getProperty("jcr:data") calls,
or whatever.

Dreaming on,
David



On 6/17/08 6:13 AM, "Jukka Zitting" <jukka.zitting@gmail.com> wrote:

Hi,

On Tue, Jun 17, 2008 at 3:57 PM, krisNog <kris.glover@bluenog.com> wrote:
> What I really need to find out is what sort of latency there is when using
> RMI to make calls to the JCR API.

Most JCR-RMI calls are remote, so you'll have the overhead of a
network roundtrip per each method call.

There's been some discussion about avoiding so many network roundtrips
by pre-fetching or caching content on the client side, but so far such
improvements have only been implemented for some simple cases like
RangeIterator.next().

BR,

Jukka Zitting



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message