Create a new FileSystemResourceLocker
Configures the locker using the specified FileSystemResourceLockerArgs instance.
Private Readonly attemptPrivate finalizedPrivate Readonly lockFolder that stores the locks
Private Readonly lockProtected Readonly loggerAcquires a lock on the requested identifier. The promise will resolve when the lock has been acquired.
Resource to acquire a lock on.
Private customPrivate generateGenerate LockOptions or UnlockOptions depending on the type of defauls given. A custom lockFilePath mapping strategy will be used.
ResourceIdentifier to generate (Un)LockOptions for
The default options. (lockFilePath will get overwritten)
LockOptions or UnlockOptions
Initializer method to be executed on server start. This makes sure that no pre-existing (dangling) locks remain on disk, so that request will not be blocked because a lock was acquired in the previous server instance.
NOTE: this also removes locks created by the GreedyReadWriteLocker. (See issue: https://github.com/CommunitySolidServer/CommunitySolidServer/issues/1358)
Releases a lock on the requested identifier. The promise will resolve when the lock has been released. In case there is no lock on the resource an error should be thrown.
Resource to release the lock on.
Private swallowWrapper function for all (un)lock operations. Any errors coming from the fn() will be swallowed.
Only ENOTACQUIRED errors wills be thrown (trying to release lock that didn't exist).
This wrapper returns undefined because retryFunction expects that when a retry needs to happen.
The function reference to swallow errors from.
Boolean or undefined.
Wrapper function for all (un)lock operations. Any errors coming from the fn() will be swallowed.
Only ENOTACQUIRED errors wills be thrown (trying to release lock that didn't exist).
This wrapper returns undefined because retryFunction expects that when a retry needs to happen.
Boolean or undefined.
Private toMap the identifier path to a unique path inside the lockFolder.
ResourceIdentifier to generate (Un)LockOptions for.
Full path.
A resource locker making use of the proper-lockfile library. Note that no locks are kept in memory, thus this is considered thread- and process-safe. While it stores the actual locks on disk, it also tracks them in memory for when they need to be released. This means only the worker thread that acquired a lock can release it again, making this implementation unusable in combination with a wrapping read/write lock implementation.
This proper-lockfile library has its own retry mechanism for the operations, since a lock/unlock call will either resolve successfully or reject immediately with the causing error. The retry function of the library however will be ignored and replaced by our own LockUtils' retryFunction function.