On 30.11.11 14:27, "Felix Meschberger" <[email protected]<mailto:[email protected]>> wrote: Am 30.11.2011 um 14:20 schrieb Michael Dürig: That's a different story for a different thread ;-) In a nutshell: under snapshot isolation sessions will see ADD events for items which do not exist for them. OTHO when they get an DELETE event the item will still exist for them. Note how this is reverse from the situation in JR2.
Hmm, this will probably effectively break many if not most current ObservationListener implementations. Good to know. 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... [0] http://www.day.com/specs/jcr/1.0/7.1.3.4_Seeing_Changes_Made_by_Other_Sessions.html [1] http://www.day.com/specs/jcr/2.0/10_Writing.html#10.1.4%20Visibility%20of%20Changes Cheers, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
