Repository navigation
Is there a way to check if a lock exists? #120
Description
Is there a way to only verify if a lock is present (i.e. the protected process is running)?
I want to do if (redLock.IsAcquired) but without actually trying to acquire a lock.
Something like this code maybe:
var lockExists = await redlockFactory.CheckForExistingLockAsync(resource);
My use case is that I have a background process that runs a long-running operation and a foreground process that enqueues process requests in RabbitMQ. If the process is already running, I would enqueue another request that I know if going to be refused.
Thanks.
Activity
samcook commentedon Sep 10, 2025
There isn't a method to directly check if a lock exists without trying to acquire it.
You could use the non blocking
CreateLockoverload (without thewaitTimeandretryTimeparameters, see here), it will return immediately so if the lock is already held thenIsAcquiredwill befalse, otherwise you'll have acquired it andIsAcquiredwill betrue.dstj commentedon Sep 10, 2025
Thanks @samcook, but wouldn't that acquire it temporarily for a few milliseconds and so, it could possibly block the "real" process from acquiring the lock too?
I'd like to avoid that.
samcook commentedon Sep 11, 2025
That's correct, in the case the lock didn't exist it would acquire it very briefly.
If your "real" process acquires the lock in a blocking way (specifying a
waitTimeandretryTimein theCreateLockoverload) it will wait to acquire the lock until the other lock is released, if it happens to trigger at a time when it's already held.It is a bit of a workaround given RedLock.net's current functionality though.
You could also check Redis directly for existence of the lock key (which by default is
redlock:your-resource-name) - if you're running with a single Redis instance that's fairly easy, if you've got multiple instances then you'd need to check them all and see whether it's held in more than half. Doing that is relying on internal implementation details though, so there's no guarantee it would work with future releases.dstj commentedon Sep 11, 2025
Yes, we ended up looking at Redis directly. I agree it's a bit of a workaround, hence my question for a native way of doing this. ;)
cbmek commentedon Dec 8, 2025
@dstj just start your "background process" also by sending RabbitMQ message, and use one Rabbit queue for all processing of the same job by handling messages. This eliminates the need od dodgy "check for lock, but don't aquire".
dstj commentedon Dec 8, 2025
@cbmek I don't believe that would work in my real use case as the resource is "one per account in a multi-tenant system". The resource key is something like
resourceId-tenantId. So the number of resources increments with each new account. exploding the number of queues. Plus, I may have multiple different messages sharing the same resource.