Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: set staleness timeout value inside the token #59

Open
pelletencate opened this issue May 8, 2019 · 0 comments
Open

Comments

@pelletencate
Copy link

pelletencate commented May 8, 2019

We need ownership of stale timeout by the process that put the lock in place, i.e. have the lock itself be aware of its stale timeout value.

If process A requests a lock, and process B requests the same lock with a staleness timeout of 30 seconds, it will recycle the lock placed by A after 30 seconds.

It would be very useful if the timeout value could be stored inside the lock itself, so that process A could lock with a 30 seconds stale timeout, which process B can respect regardless of how it was called.

This is useful if multiple processes want to acquire the same lock for different reasons, with different timeouts. For example, in a web app, a web server process could be expected to lock for example longer than 2 seconds, whereas a background job may be expected to work on the same resource for significantly longer. In that case, you don't want the web server to be able to request short-lived locks without invalidating the longer-lived locks put in place by the background workers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant