On 30.11.11 17:13, Stefan Guggisberg wrote:
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.
i guess what you mean by 'spec compliance' is 'support of all and every
optional features in the JCR spec'. and i agree with that.
jr3 should IMO be spec compliant in the sense that it passes the TCK.
which optional features should be supported is TBD.
We should clarify that quickly then. AFAIU it form that list of
goals/non-goals which is floating around on of the goals is "mvcc, only
update sessions on refresh()" which is in direct violation of the spec.
Also a non-goal on that list is nodetype consistency which AFAIK would
also violate the spec. As my example on the Wiki [1] shows, with
snapshot isolation as it is currently implemented we will not be able to
enforce node type consistency.
Michael
[1]
http://wiki.apache.org/jackrabbit/Transactional%20model%20of%20the%20Microkernel%20based%20Jackrabbit%20prototype
we don't need another JCR 2.0/2.1 reference implementation.
we already have one with jackrabbit 2.x
cheers
stefan
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
