Hi, IIUC this is not an issue with the ISMLocking implementation but rather how the query handler implementation works. can you provide a thread dump that shows the waiting thread? that would clarify what exactly causes the locking.
regards marcel MARTINEZ Antonio wrote: > 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 > > >
