Does it make sense to use redisson with jediscluster?

[SC]

Hi,

I have a distributed application that connect to a redis cluster with 3 master, 3 slaves. Each new request processed by the application results in

1) read some key

2) Increment value

3) Set key with updated value.

Question 1:

Since it is a multithreaded application, I may have two threads trying to update the same key. As such, I want to lock on the key to ensure that thread2 waits for thread1 to complete the operations before doing the same operations. I think this needs distributed locking. Am I correct?

Question 2:

I use jediscluster to read/write data to redis cluster. I also have a c++ client that reads this data from redis. Does it make sense to use redisson only for locking, while jediscluster for reading/writing my application's data from redis?

[hva...@gmail.com]

Question 1:
No, you don't need to do anything to prevent different threads (or even different processes, even running on different servers) from simultaneously update the same key.  They can't update the key simultaneously.

Redis server has a single-threaded command processing loop.  Each connected client submits commands into its own command buffer, and the Redis processing loop goes around executing the commands it finds.  When the processing loop is executing the next command from Client A, there are no other commands being processed.  None at all.  Client A's command has exclusive use of the entire database.  When that command is done, the processing loop moves to the next client with a pending command (Client B) and executes that command.  Client A's command is done and no longer executing.  Client B's command is executing.  The commands for Clients C, D, E, etc. are not being executed yet.  So there's no need for locking.

Since Redis Cluster hosts each key on only one master server (and its slaves, of course), the single-threaded command loop still works this way.  The only coordination you want to perform between clients is to make sure that all clients which are sensitive to the value of keys read them from the master servers and not from the slave servers.  Reading from the slave servers can be fine as long as the master/slave replication lag will not cause trouble.  The lag is usually very small, but if it's a problem, read from the masters instead.

Question 2:
Since you don't need to perform locking with respect to sending commands to the Redis server, you can mix Java clients and Python clients and C clients all talking to the same Redis servers.

[SC]

I know that redis is single threaded and two threads cant get/put simultaneously. My concern is that i want to lock the key while thread 1 is getting, updating and putting back data for a key in redis. I dont want to add the three operations in a synchronized block in my application because that will block all threads working on different keys. So I see below happening with my app right now -

1. thread1 gets the key (say value=1)

2. thread2 gets the key (say value=1)

3. thread1 increments value and commits new data to key (value=2)

4. thread2 increments value and commits new data to key (value=2)

I want to lock on the specific key such that at the end of both threads work, the value=3 not 2. I hope I'm clear now. Given this information, can someone please review my questions again and comment?

[Damon L.]

See here: https://redis.io/topics/distlock

Scroll down to "Correct Implementation with a single instance". Maybe this will help you.

[b...@malec.us]

Another couple of options would be the INCR or INCRBY commands, or a Lua script.

Good luck!

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
To post to this group, send email to redi...@googlegroups.com.
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.