You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The use case is a storage system (database) that uses a stale lockfile to detect crashes and then execute data recovery procedures (see albe/node-event-storage#165).
Right now, it's not possible to distinguish a lock() call that just created the lock newly from a call that reclaimed a stale lock.
The API method would need to be invoked after the new lock is claimed to prevent the recovery procedure from running twice.
This could be achieved by wrapping the callback into a method that will invoke a special onReclaimed callback similar to onCompromised at https://github.com/moxystudio/node-proper-lockfile/blob/master/lib/lockfile.js#L78
Note that this is a different case than onCompromised, as that only detects locks that can no longer be updated.
Right now to handle this scenario, the calling side needs to track the successful releasing in a separate "marker" file that gets deleted after the lock has been released. This is suboptimal though, because it introduces much more complexity and suffers from a slight inconsistency, if the process fails between releasing the lock and deleting the "marker" file.
Happy to discuss if this is a viable feature or something that unintentionally bloats the API surface of this library.
The text was updated successfully, but these errors were encountered:
Understood the feature request. It would make more sense for the lock method to return the release function as well as how the lock was obtained (standard, reclaimed). However, that would be a breaking change.
While a little bit strange, the onReclaimed seems like the way to go. If you could think about another name for onReclaimed that would include stale, the better (onStaleReclaimed sounds a bit strange, any other suggestion?).
Are you willing to implement a PR with this new feature, docs and tests?
The use case is a storage system (database) that uses a stale lockfile to detect crashes and then execute data recovery procedures (see albe/node-event-storage#165).
Right now, it's not possible to distinguish a
lock()
call that just created the lock newly from a call that reclaimed a stale lock.The API method would need to be invoked after the new lock is claimed to prevent the recovery procedure from running twice.
This could be achieved by wrapping the
callback
into a method that will invoke a specialonReclaimed
callback similar toonCompromised
at https://github.com/moxystudio/node-proper-lockfile/blob/master/lib/lockfile.js#L78Note that this is a different case than
onCompromised
, as that only detects locks that can no longer be updated.Right now to handle this scenario, the calling side needs to track the successful releasing in a separate "marker" file that gets deleted after the lock has been released. This is suboptimal though, because it introduces much more complexity and suffers from a slight inconsistency, if the process fails between releasing the lock and deleting the "marker" file.
Happy to discuss if this is a viable feature or something that unintentionally bloats the API surface of this library.
The text was updated successfully, but these errors were encountered: