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? With kind regards, Berry van Halderen
