jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "MARTINEZ Antonio" <Antonio.Marti...@alcatel-lucent.com>
Subject Read locks while Saving (using FineGrainedISMLocking)
Date Fri, 12 Sep 2008 04:24:55 GMT

I'm using JackRabbit 1.4.4.

We are facing the issue of a query taking too long while saving a big

I read about JCR-314 (Fine grained locking in SharedItemStateManager)
and modified repository.xml adding 
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.


View raw message