Repository navigation
Conversation
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
I started this branch like two years ago, but other things got in the way. The idea is to enable chaining of two or more synchronization providers, so that locks and semaphores must be acquired by all included providers. They fail or succeed together. Since I started, the CompositeDistributedSynchronizationHandle was added, and I could remove a lot of my code and use that instead.
So, what's the use case? We used it (a separate wrapper that I ended up with) when doing a rolling migration from one Azure lock account to another, and we're using it again now to migrate from Azure to Redis. All seamless, since we can ensure that locks are acquired in both places during the migration.
The second use case I see is that it together with the In Process provider (#291 ) enables us to not consume resources on the shared state if the lock was already acquired by the same process. Simply add the in process provider as the first in the chain.