madelson

@unzeitip if Redis is down then intended behavior of TryAcquireAsync should be to throw an exception (that said, we can only do this if the underlying StackExchange client propagates this...

@netdragonboberb are you saying that with the current implementation if Redis is down then TryAcquire with any timeout returns null without waiting for the full timeout to expire?

Had a chance to investigate this; it's pretty easy to replicate in the test suite: ``` var @lock = new RedisDistributedLock("abc", TestingRedis2x1DatabaseProvider.DeadDatabase); await using var handle = await @lock.TryAcquireAsync(); Assert.IsNull(handle);...

Seems like you're hitting a timeout. Some ideas: * Try reading the article linked in the error message and see if anything applies to your setup * Try both the...

@moeen thanks for your interest in the library. I can think of 2 ways to go about this depending on what exactly you're trying to achieve. One approach is to...

@moeen I wasn’t trying to imply that option 2 was the “right” answer, more that we should pick a direction depending on what you’re hoping to accomplish. Anyway, let me...

Sounds good @moeen. I should have a chance to engage on this soon.

@moeen I've thought a bit about this and I think what makes the most sense is to add 4 new methods to `DistributedLockProviderExtensions`: ``` public static ValueTask TryAcquireAllLocksAsync( this IDistributedLockProvider...

@moeen if you end up building this out, feel free to contribute it :-)

> Introduce CompositeDistributedSynchronizationHandle (implements IDistributedSynchronizationHandle) that wraps multiple handles and links their HandleLostTokens into a single CancellationTokenSource. Makes sense. This should be an _internal_ type in `DistributedLockProvider.Core`. > In GenerateProviders,...