jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From anton_slutsky <aslut...@applevac.com>
Subject Re: Jackrabbit repo locking
Date Mon, 11 Dec 2006 13:44:59 GMT

In a pure VM runtime environment this is true.  The lock is abandoned once
the VM dies.  The problem I'm having occurs in a server environment.  During
redeploy, it looks like the app server vm retains the nio lock even though
the application context should have been unloaded.  This problem is probably
due to the fact that the garbage collector  in a j2ee server is an
unpredictable entity and doesnt pick up the unloaded class instances for a
while after the undeploy occurs.  Thus, all my attempts to "shutdown()" in
finalize() are wasted.  I say "probably" because the above is something of
an educated guess --  I havent spent too much time figuring out the cause of
the issue -- but I think it's a good one.


anton_slutsky wrote:
> 
> Hello,
> 
> First of all, kudos on the great product.  We are using it and love it 
> something awful.  Having said that, one little "feature" that's there is 
> extremely annoying.  When a repo is instantiated, it creates a .lock file 
> at root (which you probably know all too well).  I'm sure there is a 
> reason for it to be there, and in prod it might even be a good idea to 
> make certain only one process access a given repository, but in 
> development, this .lock file causes a world of grief.  I'm using 
> jackrabbit as a library for a web project running on jboss in dev and 
> websphere in prod.  I constantly run into two major problems.  First, 
> sometimes, I need to kill jboss, which negates any attempts at finalize() 
> logic I have implemented.  Second, when redeploying, jboss seems to ignore 
> finalize() altogether when hot redeploying.  Obviously, this is not your 
> issue, but it is a huge inconvenience for me and my team.
> 
> I'm wondering if I were to submit a patch making this .lock logic 
> configurable, how would it go with the team?  Or are there underlying 
> architectural concerns that necessitate such an approach?
> 
> Thanks!
> Anton
> 

-- 
View this message in context: http://www.nabble.com/Jackrabbit-repo-locking-tf2590610.html#a7794936
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.


Mime
View raw message