hi berry On Mon, May 10, 2010 at 9:43 AM, Berry van Halderen <[email protected]> wrote: > 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 > logs. > - 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?
the SISM cache is reference-based, i.e. items are not evicted as long as they're currently being referenced. items managed by the LISM do keep a reference to the underlying (shared) item state. from the top of my head... the only situation where a local item state clears its reference to the underlying shared state is when it is added to the change log. if there's any chance to reproduce the issue with a junit case using plain jackrabbit i'll further investigate. cheers stefan > > With kind regards, > Berry van Halderen >
