jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <mreut...@adobe.com>
Subject RE: [jr3 trade consistency for availability]
Date Thu, 23 Feb 2012 08:09:29 GMT

> 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?


> - ...?
> 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

View raw message