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.
2) Event though I'd like it to be different, spec. compliance hasn't
been a top priority on this project so far.
Michael
[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
