Hi, > Last week's F2F resulted in an initial draft of goals for jr3 [1]. A > general direction this is taking is trading some of the consistency > guarantees for better availability (especially in a clustered set up). > As it stands - and as Jukka already noted - the specifics are currently > too vague and we need further refinements. > > What are the consistency assumptions a JCR client should be allowed to > make? > > An approach where temporary inconsistencies are tolerated (i.e. eventual > consistency) increases availability and throughput. In such a case > do/can/should we tolerate temporary violations of: > > - Node type constraints?
so far we seem to have only discussed edge cases where node type constraints could be violated. I think, they are not too relevant in a real life system. I'd be OK to make some compromises in this area. > - Access control rights? I don't think any violations are acceptable here. > - Lock enforcement? that's definitively a tough one because it depends on repository wide state. > - Query index consistency? I think consistency is a prerequisite here, otherwise it's quite difficult to implement the query functionality. I'd rather make compromises for availability. eg. terminate a long query execution with an exception because the snapshot it was working on is not available anymore. > - Atomicity of save operations? how does a temporary violation of atomic saves look like? are you thinking of partially visible changes? regards marcel > - ...? > > Should we offer alternatives in some of these cases? That is, give the > client the ability to choose between consistency and availability. > > Michael > > > [1] > http://wiki.apache.org/jackrabbit/Goals%20and%20non%20goals%20for%20J > ackrabbit%203
