Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Single-node in-memory implementation #223

Open
srogovtsev opened this issue Jul 10, 2024 · 2 comments
Open

Single-node in-memory implementation #223

srogovtsev opened this issue Jul 10, 2024 · 2 comments

Comments

@srogovtsev
Copy link

Consider the following scenario: we have a system that might run in a distributed mode and in a single-node mode. There are routines that require cross-node synchronization, so we use distributed locks. We use DI and IDistributedLockProvider to separate ourselves from the implementation details (and use different stores depending on the deployment. But when we deploy the same system in a single-node, we don't need any kind of backing store, and I would assume that the same functionality can be reasonable implemented simply in-memory, based on existing .net synchronization primitives, and just injected instead (e.g., same way as AddDistributedMemoryCache implements in-memory cache for IDistributedCache).

But I would suppose that this is a very obvious idea, and it's either that I simply missed this implementation, or there's some hidden complexity/issue that I miss, and it would be recommended to use a backing store even on single-node installations.

Will be very glad to get any pointers.

@madelson
Copy link
Owner

Hi @srogovtsev thanks for your interest in the library.

This use-case makes sense and is something I’ve considered in the past. As far as why I haven’t built it (yet):

  1. I didn’t have a real use-case outside of unit tests, and for that there are other reasonable options such as…
  2. File-based and wait handle-based locks, which are effectively local machine scoped. Of course, the latter is mostly windows-only.
  3. The implementation is simple but not entirely trivial because I’d want to retain name-based identity, meaning that 2 different lock objects with the same name need to synchronize with each other (via underlying static data structures that can’t leak memory). Another challenge is the lack of (last time I checked) a native async RW lock implementation, which id want to support.

I would call this “process-scoped synchronization”.

If this is something you’d be interested in contributing, let me know and I can offer some guidance.

@mingyangzhu
Copy link

Very useful for monolithic applications that do not want to introduce external components

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants