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