jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berry van Halderen <b.vanhalde...@1hippo.com>
Subject Modified externally exception due to eviction from shared ism cache
Date Mon, 10 May 2010 07:43:28 GMT
With some specifc data sets we've been experiencing some modified
externally exceptions in Jackrabbit 1.5.7.  I know that these are
valid exception in cases, but now I've experiencing them in a single
threaded, no observation, just one writing session (other dorment).
The modified externally exceptions all happen on a save at the
jcr:mixinTypes property, but it's not very deterministic.  With
multiple runs it only happens between 25% to 5% of the runs (the more
logging one puts in, the less frequent it occurs.  After checking my
own code I've turned to the jackrabbit code to see it there might be
an issue there.

My first attempt to resolve the issue was to alight the
o.a.j.c.NodeImpl.setMixinTypesProperty with the regular setProperty
code as that seems to be out of sync, but without success.  Therefore
I no longer think it is directly related to the jcr:mixinTypes
property, just that I'm doing a lot (thousands) of addMixin,
removeMixin.  There are other operations (copy nodes, properties set
and intermediate save to flush state). Digging deeper I stumbled on
the following thing that seems to be happening:
- A property A gets retrieved.  It will be cached by both shared Item
State Manager (ISM) and Local ISM.
- Property A gets modified and saved, the modcount in the ItemState
will be upped from the initial valie 0 to 1.
- Now a lot of other operations occur, Property A will get older and
older and will be evicted from local and shared ISM.
- Now it does look like it that A can get evicted from the shared ISM,
but not the local ISM.  This is unlikely, but this is what is in my
- Property A gets retrieved again from the same session, it is on the
local ISM cache, with modcount 1.  It gets modified.
- Now the session state is saved, to persist the state, the shared ISM
retrieved the state from the persistence manager.
- the initial modcount of this state will be 0 as it is re-retrieved.
- the conflict now is that the changelog sent from the Local ISM
contains a modcount of 1 for property A, while the related state for
property A from the shared ISM has a modcount 0.  The verification to
connect the two states will fail with a slate item state exception.

Now I can probably fix it or discuss this, but before going into
changing this, I'd like to verify with you all I've I'm not completely
in the wrong on what is happening here.  Is there a crutial step or
mechanism in place that I'm overlooking?

With kind regards,
Berry van Halderen

View raw message