Is there a way to check if a lock exists?

[dstj]

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.

[samcook]

There isn't a method to directly check if a lock exists without trying to acquire it.

You could use the non blocking CreateLock overload (without the waitTime and retryTime parameters, see here), it will return immediately so if the lock is already held then IsAcquired will be false, otherwise you'll have acquired it and IsAcquired will be true.

[dstj]

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]

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 waitTime and retryTime in the CreateLock overload) 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]

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]

@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]

@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.