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
