Hi, Am 30.11.2011 um 21:53 schrieb Jukka Zitting:
> Hi, > > On Wed, Nov 30, 2011 at 3:21 PM, Michael Dürig <[email protected]> wrote: >> 1) Does visible mean immediately visible on next access or visible after >> refresh? The second case would work with snapshot isolation. > > That's up the implementation. > > Section 10.11.1 of JSR 283 [1] explicitly allows changes to become > visible only after a refresh: "[...] items that do not have changes > pending have their state refreshed to reflect the current persisted > state, thus revealing changes made by other sessions." Ok. Thanks for the clarification. I always thought, what Jackrabbit currently does is required ... So we (thinking of Sling amongst other things) might have to adapt our event listeners to do a Session.refresh at the beginning of the onEvent method (in case long lived sessions are used). > > More generally about the write skew -issue; I don't think that's a > common problem in practice. There aren't too many clients that > explicitly interleave operations of multiple sessions within a single > thread. And in a multithreaded setup a client would even with > Jackrabbit 2.x need to use explicit synchronization to enforce more > complex content constraints. Sure. I think the main problem with long lived sessions I know of (in Sling based applications) is with Observation Listeners which are quite isolated and can be "fixed" easily -- there just has to be awareness. Regards Felix
