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? - Access control rights? - Lock enforcement? - Query index consistency? - Atomicity of save operations? - ...?

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%20Jackrabbit%203