Interface for acquiring locks for accessing or modifying the repository.

The locking mechanism makes use of flock(). This is simple, very widely available, and unlikely to leave the system in an inconsistent state. However, it availability and reliability are not universal. It will not work on NFS, some other networked file systems, and old FAT filesystems (which are really outdated at this point), so install your repository accordingly.

A read lock of the repository can be upgraded by obtaining a write lock, but calling read lock once a write lock has been obtained will not downgrade the lock to a read lock. This is different than the behavior of flock itself. While this may not seem intuitive at first, it allows for greater modularity and reuse of code. In this way locking can actually be declarative. Underlying routines which need to access files in the repository can declare the type of lock they need (shared or exclusive) and know that a lock of that level or higher has been obtained. That way, if a read operation occurs inside of a large exclusive operation, the read operation can call for a read lock without affecting the locking needs of the larger transaction. Similarly, because locks are freed automatically at the end of the script, code should generally rely on this behavior to release the lock instead of releasing it explicitly which could adversely affect locking if used within a larger transaction.

Located in /Core/lib/CriticalI/RepositoryLock.php (line 32)