Problem

The RedisTemplateSimpleDistributedLock class had an inconsistency between tryLock() and unlock() methods when handling key serialization:

• tryLock(): Used low-level RedisConnection API with manual byte conversion, bypassing custom key serializers
• unlock(): Used high-level StringRedisTemplate API which applies custom key serializers

This caused locks to fail to unlock when custom key serializers (like adding prefixes) were configured, because:

• Lock acquired with key: wechat_cp_lock:ww948:1000010:accessToken
• Unlock attempted with key: System:wechat_cp_lock:ww948:1000010:accessToken

Solution

Modified tryLock() method to use the same high-level StringRedisTemplate API as unlock():

// Before: Low-level API bypassing serializers
final byte[] keyBytes = key.getBytes(StandardCharsets.UTF_8);
List<Object> redisResults = redisTemplate.executePipelined((RedisCallback<String>) connection -> {
  connection.set(keyBytes, valueBytes, Expiration.milliseconds(leaseMilliseconds), RedisStringCommands.SetOption.SET_IF_ABSENT);
  // ...
});

// After: High-level API respecting serializers  
Boolean lockAcquired = redisTemplate.opsForValue().setIfAbsent(key, value, leaseMilliseconds, TimeUnit.MILLISECONDS);

Changes Made

• Main fix: Replaced low-level Redis API calls with high-level StringRedisTemplate API in tryLock()
• Cleanup: Removed unused imports and dependencies
• Testing: Added comprehensive test with custom key serializers
• Minimal impact: Only 10 lines added, 14 lines removed in core implementation

Testing

Added RedisTemplateSimpleDistributedLockSerializationTest which verifies:

• Lock operations work correctly with custom key serializers
• Both acquisition and release use consistent key serialization
• Reentrant behavior is maintained
• Lock exclusivity between instances is preserved

Fixes #3631.

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.