Consider supporting in-memory locking above the distributed layer (composite locking)

[madelson]

Consider supporting in-memory locking above the distributed layer (composite locking)

[dazinator]

I think one basic scenario that many people might look for is basically a replacement / substitute to this code, that makes it global:

lock(_lock)
{
// blah
}

The next might be variations of Monitor.Enter I.e so you can do the same as above but supply timeouts etc. I'd hope there would be a way to achieve that basic level of lock acquisition accross all distributed lock implementations but I havent looked closely. If there is, then that could be the basis of common interface between them.

[darkflame0]

@madelson Maybe FileDistributedLock is a proper alternative,I will try it.
thanks.

[darkflame0]

It's useful me.I'm on Windows.

[darkflame0]

but wait handles is unavailable if on linux.
I still think should have a InMemory Implementation.
It is beneficial to both test and single application

[madelson]

@darkflame0 ok prerelease is out (https://www.nuget.org/packages/DistributedLock.ProcessScoped/1.0.0-alpha01). Let me know if you get a chance to give it a try. This doesn't support composite locking yet, just the process-scoped named lock types you were asking about.

[dazinator]

Seems sensible. To go one step further, before pushing to the distributed lock layer, it might also be valuable to add a SystemDistributedLock layer in front of that again - depending on circumstance.

Question: is it a desire of this package to provide any kind of common IDistributedLock abstraction that all concrete providers will implement at a minimum? Or will it just provide different concrete lock implementations with no common interface, and leave it for application developers to build there own common abstractions around them if needed? If it's the latter then I can quickly see myself wanting to create my own common IDistributedLock abstraction, and some form of CompositeDistributedLock that implements the same interface but can wrap an inner, ordered list of lock providers (in memory, system, sql etc) that it must Aquire() a lock from first, before proceeding to the next one in the list - ultimately either timing out waiting for a lock at each level, or returning a final CompositeDisposable which wraps each of the IDisposable locks obtained.

[madelson]

Question: is it a desire of this package to provide any kind of common IDistributedLock abstraction that all concrete providers will implement at a minimum?

This is something I'm honestly a bit unsure about and definitely eager to hear feedback. In my use-cases, distributed locks aren't easily substituted because the semantics are just different (for System vs. SQL, for example). On the other hand, I could see a world where someone wanted to plug in a different implementation for deploying to a cloud environment vs. local.

[dazinator]

Yeah I think its valuable, when debugging locally I like dependencies minimal so using in memory locks is perfect. When deployed to staging and production we'd want a proper distributed lock using sql or azure blob leases etc. The only way to do that without horrible branching all over the place in the code is to create a common abstraction over the two, and make the concrete implementation actually used configurable or based on DI etc.

[darkflame0]

我认为许多人可能会寻找的一个基本场景基本上是该代码的替换/替代，这使其成为全球性的：

lock(_lock)
{
// blah
}

下一个可能是Monitor.EnterIe 的变体，因此您可以执行与上述相同的操作，但提供超时等。我希望有一种方法可以在所有分布式锁实现中实现锁获取的基本级别，但我没有仔细研究。如果有，那么这可能是它们之间通用接口的基础。

any progress?
To be honest,I need a InMemoryDistributedLock

[madelson]

Hi @darkflame0 I am not actively working on this feature, just considering it. Can you help me understand your use-case? There are a few different ones I've considered:

• In-memory named lock implementation where the named locks simplify coordination between different parts of the same application
• In-memory named lock implementation to stand in for a truly-distributed version while testing
• In-memory implementation layered on top of truly-distributed version to increase scalability (e.g. if 100 threads across 10 apps are waiting for the same named SqlDistributedLock, that's 100 database connections. However, if each thread first waited for its local in memory lock and only could claim the remote lock after acquiring that, then we'd only need 10 database connections).

What are you trying to do?

[darkflame0]

@madelson

• In-memory named lock implementation where the named locks simplify coordination between different parts of the same application
• In-memory named lock implementation to stand in for a truly-distributed version while testing

Mainly because of these two points,I need a infrastructure,it's in memory at the beginning,but can be distributed in the future.

[madelson]

@darkflame0 have you considered using FileDistributedLock or (if you are on windows) EventWaitHandleDistributedLock? These are both light-weight single-machine options.

[darkflame0]

@madelson I find out FileDistributedLock not support ReaderWriterLock and Semaphore ...

and EventWaitHandleDistributedLock not support ReaderWriterLock.

They are all Incomplete.

[madelson]

@darkflame0 yeah different technologies offer different capabilities; I only implement when I think I can offer something robust and performant on top of the particular technology.

Looking into it, I think we can build a reasonable reader-writer implementation with wait handles based on this technique. Would that be useful to you?

[madelson]

@darkflame0 I'm working on some prototypes for these. If I put out a prerelease version would you be interested in trying it out?