Is there a schedule to support redis ?

[Rwing]

No description provided.

[madelson]

@Rwing thanks for your interest in the library.

Can you clarify a bit more what you are looking for? There are Redis-specific locking libraries out there like RedLock.net (https://github.com/samcook/RedLock.net). I'd be curious to hear if you found those other libraries problematic (e. g. maybe they have bugs, licensing, or API inadequacies)? Or perhaps you are looking for a common distributed locking abstraction to rely on which could be swapped out (something DistributedLock does not offer today but which has been asked for (#10))?

I'm not intrinsically opposed to adding Redis support to DistributedLock, but I'd want to make sure it was going to add value on top of what is already available.

[Rwing]

Sorry for late reply.
I think this is a common distributed lock library, because it's named 'DistributedLock' 😀.
So the library should provide multiple policies for the user to decide which one to use.

[madelson]

@Rwing thanks for responding. We do support a few different modes today, (system-global locks backed by wait handles, distributed locks, reader-writer locks, and semaphores backed by SQL server) but not Redis yet.

I am interested in adding more implementations, but I want to avoid having the library take on a ton of different dependencies (e. g. StackExchange.Redis).

Aside from Redis, some I might consider would be MySQL GetLock (https://dev.mysql.com/doc/refman/5.7/en/locking-functions.html), PostGres advisory locks (https://www.postgresql.org/docs/9.4/explicit-locking.html), or even file-based locking.

Given the relative complexity of Redis support and availability of alternatives, I'm not planning to start it at this time but I will leave this issue open to gauge demand. Let me know if this is something you would be interested in contributing.

[Rwing]

@madelson GOOD JOB!