jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: Read locks while Saving (using FineGrainedISMLocking)
Date Fri, 12 Sep 2008 13:09:50 GMT
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//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
> 
> 
> 


Mime
View raw message