Hi, Am 30.11.2011 um 15:21 schrieb Michael Dürig:
> > > On 30.11.11 13:57, Alexander Klimetschek wrote: >> I expect there is a lot of code outside that relies on the copy-on-write >> nature of JR 2 - i.e. that anything the session did not touch yet is >> always "live". Introducing snapshot isolation (which would be >> copy-on-read IIUC) would break those cases (but usually these errors >> will depend on concurrency, thus hard to spot). >> >> Now looking at the specs, I am confused: in JCR 1.0 it was up to the >> implementation to be using copy-on-read or copy-on-write [0]. In JCR 2.0 >> that text was replaced by [1] (IIUC, didn't find anything else) which >> seems to be defining copy-on-write as the standard behavior now: >> >> "A change that is persisted is visible to all other sessions bound to >> the same persistent workspace that have sufficient read permission." >> >> That would mean that JR 3 cannot do snapshot isolation! But I might be >> missing something... > > Good catch! Two points: > > 1) Does visible mean immediately visible on next access or visible after > refresh? The second case would work with snapshot isolation. Well "visible after refresh" is a conditional visibility IMHO, while "visible" as in the spec is more like unconditional (always under the assumption of having read access, of course). Regards Felix
