Skip to content
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

Implement #watch and #multi specially for cluster-client #1256

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

KJTsanaktsidis
Copy link
Contributor

This PR makes watch & multi work more or less the same way for clustering as they do for normal redis.

Since it's supposed to be valid to perform your multi call on the original redis object, like this:

redis.watch('key') do
  redis.multi do |tx|
    # tx is performed on the same connection as the watch
  end
end

we need to keeps some state in an ivar @active_watcher so we know to call MULTI on the same actual connection as WATCH (and appropriately fail if the keys got redirected or the node went down). This is technically threadsafe, because the watch/multi implementation is wrapped in the synchronize monitor; however, for good performance in multithreaded environments, you will most likely want to use a connection pool of Redis::Cluster instances.

(note - this will need redis-rb/redis-cluster-client#339 to be merged in order to work. But "the tests pass on my machine, I promise" 😂 )

This PR makes watch & multi work more or less the same way for
clustering as they do for normal redis.

Since it's supposed to be valid to perform your multi call on the
original redis object, like this:

```
redis.watch('key') do
  redis.multi do |tx|
    # tx is performed on the same connection as the watch
  end
end
```

we need to keeps some state in an ivar @active_watcher so we know to
call MULTI on the same actual connection as WATCH (and appropriately
fail if the keys got redirected or the node went down). This is
technically threadsafe, because the watch/multi implementation is
wrapped in the `synchronize` monitor; however, for good performance in
multithreaded environments, you will most likely want to use a
connection pool of Redis::Cluster instances.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant