chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Müller <>
Subject Re: NavigationServiceImpl excessively resets cache
Date Fri, 18 Mar 2011 12:18:44 GMT
Hi Alex,

Not the link cache gets reset, but the links for a particular object get refreshed.
The links are parts of the Atom entry. So we retrieve them anyway. There is no additional
roundtrip. We only process data that we already have at that moment in time.

You could argue that the links don't change and therefore don't need to be refreshed. So,
yes, we could save a few in-memory Map operations by not refreshing them.
But there is one exception to the rule that requires refreshing: Links can be appear and disappear
over time. 
The "alternate" link, for example, points to the renditions of a document. Some repositories
create and remove renditions asynchronously. So when you look at newly created document, there
is no "alternate" link. If look at the same document a few seconds/minutes/hours later the
repository has generated a rendition and the link shows up.

- Florian

On 18/03/2011 11:52, Alexander Chow wrote:
> Hi all,
> I've been looking at the caching in OpenCMIS and I noticed that org.apache.chemistry.opencmis.client.bindings.spi.atompub.NavigationServiceImpl
does a lot of resetting of the link cache. In particular, these methods:
> getChildren()
> getFolderParent()
> getCheckedOutDocs()
> call removeLinks(), followed by an addLink() for every link found. This means anytime
you do one of those calls, which in my case is quite often, all those caches get reset. This
is true in several other services like VersioningServiceImpl.getAllVersion() and RelationshipServiceImpl.getObjectRelationships().
> My question is if this is excessing resetting of the link cache. Basically, since my
implementation does getChildren() or getFolderParent() a lot, it loses all those link caches
and has to do (in my eyes) excessive round trips on the same object.
> Alex

View raw message