Refactor RedisLockRegistry to leverage Redis 8.4 native CAS/CAD commands

[Dgramada]

RedisLockRegistry could make use of the new native CAS/CAD commands introduced in Redis 8.4, which will be available in Spring Data Redis 4.1.0.

A proper example would be the RedisSpinLock which could use the new deleteIfEqual(lockKey, clientId) template method instead of the current Lua script.
Furthermore, the current OBTAIN_LOCK_SCRIPT could be simplified by calling SET with the IFEQ option instead of calling two separate commands.

Current Behavior

RedisLockRegistry currently uses Lua scripts to call multiple operations as one command.

Additionally, RedisMessageStore.doRemove() performs two separate operations which can be replaced with the currently available template command setGet() introduced in Redis 6.2 as GETDEL.

Context

The Redis OSS ecosystem team would like to contribute this enhancement.

The current Lua script approach works correctly but introduces overhead from script parsing and execution. With Redis 8.4 introducing native CAS/CAD commands, there's an opportunity to simplify the implementation and improve performance.

We aim to:

• Replace applicable Lua scripts with native Redis 8.4 CAS/CAD commands
• Simplify code maintenance by using direct API calls instead of embedded Lua scripts
• Optimize RedisMessageStore.doRemove() using GETDEL for atomic get-and-delete

Questions for the maintainers:

1. Is this change meaningful to you?
2. Do you have backwards compatibility requirements?
3. Should we maintain support for Redis versions prior to 8.4?
4. If yes, what is your preferred approach:

• Runtime detection with fallback to Lua scripts?
• Configuration option to choose implementation?
• Separate implementation classes?

6. What is the lowest Redis version you would like to support?

[artembilan]

Thank you for look into this and for suggesting a help with its implementation!

For now I put this into backlog since we cannot start looking into this until the mentioned new API appears in Spring Data Redis.
We will come back to details then later, however I think we would require same backward compatibility down to that Redis version which is going to be yet supported by Spring Data Redis 4.1.

Looks RedisMessageStore.doRemove() deserves its own GH issue and separate fix which can be performed now.
Would you mind taking care of that?

Thank you again!

[artembilan]

We've just switched our main to the latest Spring Data 2026.0.0.
Feel free to open pull request with the fix for this concern at your convenience.
Yes, we do have to preserve some backward compatibility.
For now it is at least down to Redis 4: #10460.

Runtime resolution or fallback would be great to have.

Thanks

[Dgramada]

Hi, I would like to give an update concerning this issue. The CAS/CAD PR for spring-data-redis has been postponed.

[Dgramada]

Hi, the CAS/CAD logic has been merged to Spring Data Redis and is available in the main branch.
References:
CAS
CAD

[artembilan]

Sounds good, @Dgramada !

Let us know if you are willing to contribute such a feature: https://github.com/spring-projects/spring-integration/blob/main/CONTRIBUTING.adoc.

It would be grate to make it now for the current 7.1.0-RC1 to align fully with Spring Data we are relying on in this version.

Thanks