jackrabbit-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jackrabbit Wiki] Update of "RepositoryLock" by ThomasMueller
Date Mon, 19 Oct 2009 12:58:42 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification.

The "RepositoryLock" page has been changed by ThomasMueller.
http://wiki.apache.org/jackrabbit/RepositoryLock

--------------------------------------------------

New page:
== Repository Locking ==

The repository lock mechanism ensures that only one Jackrabbit instance can open the same
repository at one time. By default, when a repository is started, Jackrabbit tries to create
a file named .lock in the repository home directory and protects it using using a native file
lock. If the repository is already in use, this will fail, usually with one of the following
exceptions / entries in the log file:

{{{
Existing lock file at  ../.lock detected. Repository was not shut down properly.
javax.jcr.RepositoryException: 
The repository home ... appears to be in use since the file named .lock is locked by another
process.
or
The repository home ... appears to be in use since the file named .lock is already locked
by the current process.
or
OverlappingFileLockException
}}}

In the first case, the repository is already open in another process. Please stop the other
process first.

In the second and third case, the repository is already open in the same process but within
another class loader (for example, in another web application). In this case you need to ensure
that the repository is closed when the web-application is stopped.

== Using the Cooperative File Lock Mechanism ==

Some NFS implementations do not release native locks after a hard reboot. In this case the
workaround is to manually delete all .lock files. Older NFS implementation throw the exception
"No locks available", which means the NFS does not support native file locks.

To solve this problem, Jackrabbit also supports cooperative file locking. This mechanism is
not based on native file locks, but instead uses background threads that periodically update
a sentinel file (lock.properties). The algorithm of cooperative file locking is described
below. To use cooperative file locking, add this to your repository.xml before the </Repository>
tag:

{{{
<RepositoryLockMechanism class="org.apache.jackrabbit.core.util.CooperativeFileLock" />
}}}

=== Cooperative File Locking Algorithm ===

The cooperative file locking works as follows:

 * If the lock.properties file does not exist, it is created (using the atomic operation File.createNewFile).
Then, the process waits a little bit and checks the file again. If the file was changed during
this time, the operation is aborted. This protects against a race condition when one process
deletes the lock file just after another one create it, and a third process creates the file
again. It does not occur if there are only two writers.

 * If the file can be created, a random id is inserted. Afterwards, a watchdog thread is started
that checks regularly (every second once by default) if the file was deleted or modified by
another (challenger) thread or process. Whenever that occurs, the file is overwritten with
the old data. The watchdog thread runs with high priority so that a change to the file does
not get through undetected even if the system is very busy. However, the watchdog thread does
use very little resources (CPU time), because it waits most of the time. Also, the watchdog
only reads from the hard disk and does not write to it.

 * If the file exists and was recently modified, the process waits for some time (up to two
seconds). If it was still changed, an exception is thrown. This is done to eliminate race
conditions with many concurrent writers. Afterwards, the file is overwritten with a new version
(challenge). After that, the thread waits for 2 seconds. If there is a watchdog thread protecting
the file, he will overwrite the change and this process will fail to lock the repository.
However, if there is no watchdog thread, the file will still be as written by this thread.
In this case, the file is deleted and atomically created again. The watchdog thread is started
in this case and the file is locked. 

Mime
View raw message