Skip to content

RedisTemplate.hasKey() Behavior Change with setEnableTransactionSupport = true #2886

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
leeyohan93 opened this issue Apr 2, 2024 · 1 comment
Assignees
Labels
type: regression A regression from a previous release

Comments

@leeyohan93
Copy link

leeyohan93 commented Apr 2, 2024

When setEnableTransactionSupport is set to true in RedisTemplate,
the behavior of RedisTemplate.hasKey() may differ depending on the version of Spring Data Redis:

  • In version 2.7.X: hasKey() responds with a valid value.
  • In version 3.0.X ~ 3.2.X: hasKey() responds with null.

Based on the code debug, it appears that the introduction of RedisTemplate.doWithKeys() may have led to a change in the behavior of ConnectionSplittingInterceptor.intercept() In version 2.7, the invoke method at line 487 is called, while in version 3.0, the invoke method at line 477 is called.

In recent Spring Data Redis documentation, it is mentioned that "Read-only commands" are designed to work well in transactional contexts. However, it's unclear whether the exclusion of the hasKey command from this behavior is intentional or a bug.

I am using spring data redis well. Thank you

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Apr 2, 2024
@mp911de mp911de added type: regression A regression from a previous release and removed status: waiting-for-triage An issue we've not yet triaged labels Apr 2, 2024
@mp911de
Copy link
Member

mp911de commented Apr 2, 2024

This is a regression we introduced with the new command interface design. In fact, trying to obtain a command interface first breaks ConnectionSplittingInterceptor as ConnectionSplittingInterceptor expects a Redis command invocation instead of the intermediate command interface to be returned.

@mp911de mp911de self-assigned this Apr 2, 2024
christophstrobl pushed a commit that referenced this issue Apr 11, 2024
…eptor`.

We now consider requests to command API objects such as RedisConnection.keyCommands() in ConnectionSplittingInterceptor to identify the correct command and route it accordingly.

Closes: #2886
Original Pull Request: #2887
@christophstrobl christophstrobl added this to the 3.2.5 (2023.1.5) milestone Apr 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: regression A regression from a previous release
Projects
None yet
4 participants