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//nodeLevel_1[@p1='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