Enhancing unlock() Method of RedisLock with Atomic Redis Operation

[EddieChoCho]

Expected Behavior

Using a single Lua script to verify ownership of the lock and remove it.

Current Behavior

unlock() method of RedisLock uses two separate Redis operations:

1. isAcquiredInThisProcess() method executes a GET operation to verify if the lock is owned by the process.
2. removeLockKey() method executes UNLINK/DEL operation to remove the lock.

Context

The current implementation of the unlock() method involves two distinct Redis operations. However, I'm wonder if this approach may lead to potential issues? particularly in edge cases where the lock expires and is subsequently obtained by another process before the original process attempts to delete it:

1. Process A performs a GET 'key' operation to check if it owns the lock.
2. 'key' expired.
3. Process B acquires the lock by executing OBTAIN_LOCK_REDIS_SCRIPT with 'key' and clientId of process B.
4. Process A proceeds to execute a UNLINK/DEL operation to remove the 'key'.

To address this, it is proposed that the unlock method be enhanced to employ a single atomic Lua script. This script will both verify ownership of the lock and remove it. This approach ensures that the process of unlocking remains atomic and immune to race conditions or interleaved operations, thus maintaining the integrity of the distributed lock mechanism.

[artembilan]

Fixed via 0450a32