feat: add experimental lock option with no-op default #731
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hf
commented
Jul 12, 2023
hf
force-pushed
the
hf/use-lock
branch
3 times, most recently
from
18b64b0
to
abce2ae
Compare
hf
commented
Jul 13, 2023
hf
commented
Jul 13, 2023
hf
force-pushed
the
hf/use-lock
branch
5 times, most recently
from
14c9acc
to
0f3b9ad
Compare
J0
reviewed
Jul 14, 2023
| 'lock is already acquired, skipping for next tick' | ||
| ) | ||
| } else { | ||
| console.error('Auto refresh tick failed with error. This is likely a transient error.', e) |
There was a problem hiding this comment.
What would be the best way to advise a customer to debug this if they come back to us with an error? Wondering how we'd advise to support how to classify whether whether no action is needed vs it's something we should investigate
There was a problem hiding this comment.
It's transient, but logging so it's not silent.
J0
approved these changes
Jul 14, 2023
|
I will actually re-open with the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds an
@experimentallockoption and uses it in_useSession. This can be used to test out different lock implementations before committing to a default one within this library.It includes an implementation of a
broadcastLockwhich can be used as a value tolockbut is not done by default intentionally. This is an experimental API that is bound to have changes and potentially serious bugs. Once it has been well tested by the team and others it is likely to be promoted to the default option.broadcastLock
Uses a
BroadcastChannelto serialize access to a named critical section. The lock has three states: Acquiring, Backoff and Acquired.When in the Acquiring state, a message is broadcast
I will acquire the lock!and a timeout is started. If any message is received in this state, the lock immediately moves to the Backoff state. If no message is received, the lock moves to the Acquired state. It is assumed that if two messages are posted simultaneously at the channel, that both locks will receive the other's message.When in the Backoff state, the lock sleeps for random amount of time before moving back in the Acquiring state. Each time it enters this state, it waits exponentially longer than the last time.
When in the Acquired state, the lock broadcasts
I have the lock, please wait!. If any message is received on the channel,I have the lock!is broadcast immediately. The sender of the firstI will acquire the lock!message received in this state will be sent theGomessage after the operation is done which gives it priority over all other competing locks. This helps reduce the time needed for the locks to identify who should go next. Once the operation is done, the lock stops replying withI have the lock, please wait!messages on the channel.