jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@day.com>
Subject Re: Jackrabbit 1.6 and DavEx ?
Date Thu, 20 May 2010 14:12:58 GMT
hi john

> I just discovered something that looks like a strange behaviour to me
> and I would like to check whether it is expected or not.
> With jcr2spi the cache seems to be handled per session.
> Here is a sequence to illustrate it :
> 1. Create jcrSession1
> 2. Create jcrSession2
> 3. Add a node n with jcrSession1

and save(), right?

> 4. ItemExists(n) with jcrSession2 returns false
> 5. Add a node n with jcrSession2 ==> Exception ItemExists
> If I swap point 2. and 3. (i.e. I create jcrSession2 after adding the
> node n with jcrSession1) everything works fine.
> Is there a reason I don't know to handle the cache at the session
> level and not at the repository proxy level ?

we made some optimizations regarding the caching behavior in the
past (i don't recall for which version exactly though) in order
to minimize the number of round trips to the SPI layer, which
possibly includes expensive network roundtrips. one that might be 
related to the problem described is a flag with childnodeentries that 
defines if the list is complete at the point of being populated
-> refresh is required in order to force a reload of the list.

> And beside that, is there a way to invalidate the cache of a session
> (apart from closing and reopening a session) ?

Session.refresh() and Item.refresh() should do the trick. it's
the JCR way to force reloading of the status visible to a particular

one more thing was the CacheBehavior configuration flag:

with jcr2spi running in CacheBehavior.OBSERVATION mode the
refresh call is a nop as in this configuration all changes from
the SPI should be automatically update the existing clients (jcr2spi 
Sessions)... i didn't try this one for a while, though.

with jcr2spi running in CacheBehavior.INVALIDATION (default)
you may need an explicit/manual refresh call to get the latest
state of the persistent layer (SPI implementation).

hope that helps

View raw message