5 ms·

According to the first comment, the part about locking the whole data set for MULTI is not accurate. Only the connection calling that is stalled, which makes pe

According to the first comment, the part about locking the whole data set for MULTI is not accurate. Only the connection calling that is stalled, which makes perfect sense.

IgorPartola 16y ago
Ah: http://redis.io/commands/multi http://redis.io/commands/multi. So the problem with this approach is that there are no consistent reads. If I say: MULTI get foo # Returns 'abc' set foo 'abcd' # (as in application code said foo += 'd') EXEC while another process sets foo to 'xyz' between my get and set, I just overwrote that value. No serializable transactions.
- lukesandberg 16y ago
  im not exactly sure about that but i know that at least for integers there are atomic update commands and that for strings there are atomic append commands. so for this you would really just want to do: APPEND foo d or for more complex situations you could do use WATCH instead of MULTI so that you can get the intermediate results. so for your example: WATCH foo GET foo ->value //calculate new_value MULTI SET foo new_value EXEC now if at any other operation (not part of this connection) modifies foo then the transaction will be aborted. GET foo -> value //application logic to update value GETSET foo new_value ->prev then prev will contain the value of foo at the time it was set, so you can then use application logic to roll back or redo the transaction
- deleted 16y ago
  [deleted]
- liuliu 16y ago
  Redis is single-thread one-process program. Since the execution only happens when EXEC command received, such scenario cannot exist.
- antirez 16y ago
  MULTI/EXEC is completely atomic and transactional. You can perform just writes inside the block. If you want atomicity with reads in the middle, you need to use WATCH/MULTI/EXEC that uses an optimistic locking algorithm.
  - IgorPartola 16y ago
    Ah, that makes sense. I imagine allowing atomic reads without WATCH would complicate the code quite a bit.
    - antirez 16y ago
      Indeed, not very Redis-ish :) With WATCH is very easy. WATCH this keys. Perform your reads. Prepare to write in a transaction. If at least one key was modified in the meantime the transaction will fail.
      - x09 16y ago
        Salvatore, you do realize that now you need to put a Klashnikov on the new Redis logo? :p

According to the first comment, the part about locking the whole data set for MULTI is not accurate. Only the connection calling that is stalled, which makes perfect sense.

IgorPartola 16y ago

Ah: http://redis.io/commands/multi http://redis.io/commands/multi. So the problem with this approach is that there are no consistent reads. If I say: MULTI get foo # Returns 'abc' set foo 'abcd' # (as in application code said foo += 'd') EXEC while another process sets foo to 'xyz' between my get and set, I just overwrote that value. No serializable transactions.

lukesandberg 16y ago
im not exactly sure about that but i know that at least for integers there are atomic update commands and that for strings there are atomic append commands. so for this you would really just want to do: APPEND foo d or for more complex situations you could do use WATCH instead of MULTI so that you can get the intermediate results. so for your example: WATCH foo GET foo ->value //calculate new_value MULTI SET foo new_value EXEC now if at any other operation (not part of this connection) modifies foo then the transaction will be aborted. GET foo -> value //application logic to update value GETSET foo new_value ->prev then prev will contain the value of foo at the time it was set, so you can then use application logic to roll back or redo the transaction
deleted 16y ago
[deleted]
liuliu 16y ago
Redis is single-thread one-process program. Since the execution only happens when EXEC command received, such scenario cannot exist.
antirez 16y ago
MULTI/EXEC is completely atomic and transactional. You can perform just writes inside the block. If you want atomicity with reads in the middle, you need to use WATCH/MULTI/EXEC that uses an optimistic locking algorithm.
- IgorPartola 16y ago
  Ah, that makes sense. I imagine allowing atomic reads without WATCH would complicate the code quite a bit.
  - antirez 16y ago
    Indeed, not very Redis-ish :) With WATCH is very easy. WATCH this keys. Perform your reads. Prepare to write in a transaction. If at least one key was modified in the meantime the transaction will fail.
    - x09 16y ago
      Salvatore, you do realize that now you need to put a Klashnikov on the new Redis logo? :p