How to get lock with a key

[tshubham19]

This is not an issue, just a question. How do we get lock having just a key value. We need this option in the scenarios when we acquire a lock in a thread and try to release the same lock in the other thread. Thanks team,

[dim]

At the moment, you cannot, but could you just share the Lock instance across threads (protected by a mutex, obviously)? Happy to accept a PR where a Lock can be created from a key.

[janosmiko]

I created a PR that should (hopefully) make it possible.

https://github.com/bsm/redislock/pull/51

[timo-klarshift]

What If I want to release form another process ? I cannot share it. It would be super helpful in a replicated application environment

[janosmiko]

@timo-klarshift you can use my fork.

Instead of the regular Obtain, call it like this:

// Try to obtain lock.
locker.Obtain(ctx, "my-key", 150*time.Millisecond, &redislock.Options{
    Secret: "test",
})

If the second application uses the same secret, it will be able to obtain (and release) the lock.

[dim]

@timo-klarshift @janosmiko I would be more than happy to incorporate your fork into our version, but I still don't understand how locking and releasing from separate processes can be beneficial. I can see many side-effects from having a shared Secret. Could you please explain the use case where this may be beneficial? Normally, you would want a distributed lock so that multiple processes don't perform the same task concurrently.

[janosmiko]

I tried to explain my use case in the PR. But here's a pretty simple one:

• Application A is running in a Kubernetes pod, and obtains lock for a long time (let's say 3 minutes)
• Application B is trying to obtain the same lock but it doesn't know the secret so it's going to fail and retry later
• Application A fails. Kubernetes automatically restarts the pod. The next instance of Application A will have to wait 2 and a half minutes (or if it knows the previous secret, it can reobtain the lock and it can continue or restart the process)
• Application A finishes the process, releases the lock
• Application B obtains the lock

[dim]

So to confirm, this is purely to prevent process/application A from waiting when trying to re-acquire the lock in step 3?

[janosmiko]

The idea is to make it possible to release the lock from other processes. In this case, in step 3 the application is able to obtain (and release) the previous lock.

[dim]

@janosmiko Please see #66

[sambarnes]

@dim looks solid to me :) any idea on timing for the release?

just judging whether i should roll my own temporarily for now, cheers

[dim]

@sambarnes sorry, forgot about this, will release today

[sambarnes]

@dim legend 🙇

[michatw]

Hey! @dim I think I'm missing something but I can not quite comprehend how this PR (https://github.com/bsm/redislock/pull/66) solves the issue. @janosmiko checks in his fork (https://github.com/janosmiko/redislock/blob/main/redislock.go see line 116) whether the stored value equals the value that should be stored. If this is the case it means the process trying to obtain the lock knows the shared secret/token (whatever you wanna call it;-)) and is allowed to reobtain it. Where is this done in your code?

[dim]

@michatw good point, missed this

[dim]

@michatw is this what you had in mind https://github.com/bsm/redislock/pull/71?

[michatw]

@michatw is this what you had in mind #71?

@dim LGTM. Thanks for your fast response!