jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-863) Patch to use FileLock for locking instead of empty file
Date Thu, 24 May 2007 08:15:16 GMT

    [ https://issues.apache.org/jira/browse/JCR-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498541

Stefan Guggisberg commented on JCR-863:

> Have looked into the other JIRA - on second look I am not sure if its a problem, as this
uses lock() not tryLock, which is fail fast and exclusive. A bigger problem is the issue of
JRE implementation on a given platform, not entirely sure how much this can be relied on.

the file locking issue discussed in JCR-912 and JCR-933 applies to both FileChannel#lock()
& FileChannel#tryLock():

A. as of java 1.6 the behaviour of lock() and tryLock() has changed. both methods now consistently
    an OverlappingFileLockException on all platforms if the the lock is already held by the
current process.

B. in java 1.4 & 1.5 lock() and tryLock() have a platform-dependant behaviour if the lock
is already held 
    by the current process::

    on windows:
        lock() blocks!
        tryLock() returns null

    on *nix:
        lock() and tryLock() return a new FileLock object!
note that A. is the correct behaviour according to the javadoc. 

since lock() doesn't always fail fast (it potentially blocks) i suggest using tryLock() instead.
the suggested fix in JCR-933 addresses the incorrect & platform dependant behaviour
described in B.

> Patch to use FileLock for locking instead of empty file
> -------------------------------------------------------
>                 Key: JCR-863
>                 URL: https://issues.apache.org/jira/browse/JCR-863
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: query
>            Reporter: Michael Neale
>             Fix For: 1.4
>         Attachments: FSDirectory.patch, JCR-863.patch
> The FSDirectory uses File.createNewFile to effectively lock a directory (in makeLock),
yet the Java Spec says explcitly not to use it for this purpose, and instead use FileLock
from nio.
> The attached patch shows how this is/could be done (change is internal to the makeLock
method only, and functionally equivalent, the same tests apply).

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message