Hello,
I'm using JackRabbit 1.4.4.
We are facing the issue of a query taking too long while saving a big
Tree.
I read about JCR-314 (Fine grained locking in SharedItemStateManager)
and modified repository.xml adding
<ISMLocking
class="org.apache.jackrabbit.core.state.FineGrainedISMLocking">
</ISMLocking>
Still the query locks if I do it while saving the tree.
This is the structure of our repository (the tree is actually more than
10 levels deep)
rootNode ---- nodeLevel_1 (p1=a, p2=x, ..) --- nodeLevel_2 (p1=t, p2,
..)
--- nodeLevel_2 (p1=u, p2,
..)
--- nodeLevel_2 (p1=v, p2,
..)
--- nodeLevel_2 (p1=w, p2,
..)
nodeLevel_1 (p1=b, p2=y, ..) --- nodeLevel_2 (p1=m, p2,
..)
--- nodeLevel_2 (p1=n, p2,
..)
--- nodeLevel_2 (p1=o, p2,
..)
--- nodeLevel_2 (p1=p, p2,
..)
I'd like to know how FineGrainedISMLocking actually works and if there
is something more we can do to avoid the query from waiting on a lock.
- Let's assume I write the tree under "nodeLevel_1 (p1=a, p2=x, ..)".
Should the query //rootNode//[EMAIL PROTECTED]'b'] lock for the write
to finish ? It actually locks now
Maybe read locks because needs to evaluate nodeLevel_1 (p1=a, p2=x,
..) in case p1 actually also equals 'b'?
In our case p1 is has a UNIQUE value for each nodeLevel_1. Can we
somehow let JR know that so it does not wait?
Is there a way for read to actually go ahead best effort returning
only those matches not locked by write?
I really appreciate any help, this is a show stopper issue for us.
Thanks,
Antonio
