On 30.11.11 20:53, Jukka Zitting 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."
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.
Ok, sounds reasonable to me as far as application constraints are
involved. Note however, that for the same reason we are currently not
able to guarantee node type consistency:
session1 = login()
session2 = login()
n1 = session1.getNode("n")
n1.setPrimaryType(nt:file)
n1.save()
n2 = session2.getNode("n")
n2.addNode("foo")
n2.save()
Both sessions will successfully complete since for each of them the
consistency property (nt:file cannot have a child named "foo"). holds.
The combined effect however will result in node n being of type nt:file
and having a child node foo.
We could fix this by implementing Tom's test-and-set operator [1] in the
microkernel.
Michael
[1] http://markmail.org/message/c32jpeoxklgcrybr
[1] http://www.day.com/specs/jcr/2.0/10_Writing.html#10.11.1%20Refresh
BR,
Jukka Zitting
