Examples of FileLock

• com.arjuna.ats.arjuna.utils.FileLock
  Sometimes it is necessary to lock a file at the disk level. Since there is no native Java way of locking a file, we have to implement our own. Unfortunately, it appears as though we can only assume that rename is atomic. We base the locking on this then: rename the lock file and update it with the lock owners. How it works: for every file we want to lock we create an _lock file. This file contains information about who is locking the file, and in what mode. (Single writer, multiple readers.) To guarantee atomicity of update, we move (rename) the actual file each time we want to lock it and update the lock file. When this is done, we move (rename) it back. Almost like a two-phase commit protocol! Currently we don't support re-entrant locking. @author Mark Little (mark@arjuna.com) @version $Id: FileLock.java 2342 2006-03-30 13:06:17Z $ @since JTS 1.0. @message com.arjuna.ats.arjuna.utils.FileLock_1 [com.arjuna.ats.arjuna.utils.FileLock_1] - FileLock.lock called for {0} @message com.arjuna.ats.arjuna.utils.FileLock_2 [com.arjuna.ats.arjuna.utils.FileLock_2] - FileLock.unlock called for {0} @message com.arjuna.ats.arjuna.utils.FileLock_3 [com.arjuna.ats.arjuna.utils.FileLock_3] - FileLock.createFile called for {0} @message com.arjuna.ats.arjuna.utils.FileLock_4 [com.arjuna.ats.arjuna.utils.FileLock_4] - An error occurred while creating file {0} @message com.arjuna.ats.arjuna.utils.FileLock_5 [com.arjuna.ats.arjuna.utils.FileLock_5] - FileLock.lockFile called for {0} @message com.arjuna.ats.arjuna.utils.FileLock_6 [com.arjuna.ats.arjuna.utils.FileLock_6] - FileLock.unlockFile called for {0}
• java.nio.channels.FileLock
  A FileLock represents a locked region of a file.

  Locks have certain properties that enable collaborating processes to avoid the lost update problem, or reading inconsistent data.

  logically, a file lock can be 'exclusive' or 'shared'. Multiple processes can hold shared locks on the same region of a file, but only a single process can hold an exclusive lock on a given region of a file and no other process can simultaneously hold a shared lock overlapping the exclusive lock. An application can determine whether a FileLock is shared or exclusive via the isShared() API.

  Locks held by a particular process cannot overlap one another. Applications can determine whether a proposed lock will overlap by using the overlaps(long, long)

  Locks are shared amongst all threads in the acquiring process, and are therefore unsuitable for intra-process synchronization.

  Once a lock is acquired it is immutable in all its state except isValid(). The lock will initially be valid, but may be rendered invalid by explicit removal of the lock, using release(), or implictly by closing the channel or exiting the process (terminating the JVM).

  Platform dependencies

  Locks are intended to be true platform operating system file locks, and therefore locks held by the JVM process will be visible to other OS processes.

  The characteristics of the underlying OS locks will show through in the Java implementation. For example, some platforms' locks are 'mandatory' -- meaning the operating system enforces the locks on processes that attempt to access locked regions of file; whereas other platforms' locks are only 'advisory' -- meaning that processes are required to collaborate on ensuring locks are acquired and there is a potential for processes not to play well. The only safe answer is to assume that the platform is adopting advisory locks an always acquire shared locks when reading a region of file.

  On some platforms the presence of a lock will prevent the file being memory mapped. On some platforms closing a channel on a given file handle will release all the locks held on that file -- even if there are other channels open on the same file (their locks will be released). The safe option here is to ensure that you only acquire locks on a single channel for a particular file, and that becomes the synchronization point.

  Further care should be exercised when locking files maintained on network file systems since they often have further limitations.

• org.exist.storage.lock.FileLock
  Cooperative inter-process file locking, used to synchronize access to database files across processes, i.e. across different Java VMs or separate database instances within one VM. This is similar to the native file locks provided by Java NIO. However, the NIO implementation has various problems. Among other things, we observed that locks were not properly released on WinXP. FileLock implements a cooperative approach. The class attempts to write a lock file at the specified location. Every lock file stores 1) a magic word to make sure that the file was really written by eXist, 2) a heartbeat timestamp. The procedure for acquiring the lock in {@link #tryLock()} is as follows:If a lock file does already exist in the specified location, we check its heartbeat timestamp. If the timestamp is more than {@link #HEARTBEAT} milliseconds in the past, we assumethat the lock is stale and its owner process has died. The lock file is removed and we create a new one. If the heartbeat indicates that the owner process is still alive, the lock attempt is aborted and {@link #tryLock()} returns false.Otherwise, we create a new lock file and start a daemon thread to periodically update the lock file's heart-beat value. @author Wolfgang Meier
• org.h2.store.FileLock
  The file lock is used to lock a database so that only one process can write to it. It uses a cooperative locking protocol. Usually a .lock.db file is used, but locking by creating a socket is supported as well.
• org.openide.filesystems.FileLock