jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tobias Bocanegra" <tobias.bocane...@day.com>
Subject Re: Jackrabbit repo locking
Date Wed, 08 Nov 2006 08:25:35 GMT
hi anton,
we received many errors that were caused by multiple instances running
on the same repository data that's why the .lock file is there to
prevent 2 jackrabbit instances accessing the same physical data.
actually, it should not cause any trouble, even if the jvm is killed
or the repository is not shut down correctly.
the mechanism works as follows: if the .lock file is present, the
repository tries to acquire a java.nio.lock, and if this succeeds,
only a warning is issued. if not, another process has locked the file
and the repository startup is aborted. if the jvm is killed, it
releases also the lock of on the .lock file.

so i'm wondering what exact problems you see?
regards, toby

On 11/7/06, anton_slutsky <aslutsky@applevac.com> 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#a7224255
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>


-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---

Mime
View raw message