Hacker News Reader

Comment by antirez | Hacker News Reader

basically MULTI/EXEC is always handled correctly, either everything or nothing is committed to the database memory, RDB file, AOF file, slave, ...

View on HN

I had read that MULTI/EXEC would not "rollback" incase a command fails (e.g. you do first SET, second SET, third SET fails, then the two initial SETs would still be applied). I guess this doesn't so much have to do specifically with persistance problems (system crash, process crash, etc..) but more with just how transactions work in general.

Is this not true or at least no longer true?

http://redis.io/commands/set

> Status code reply: always OK since SET can't fail.

So, what kind of situation are you envisioning?

Maybe SET wasnt a good example .. but lets say you are writing to the wrong type or something like that. I know that its unlikely something will fail in production like that since you should catch it during dev but bugs can happen.

  redis> multi
  OK
  redis> set hi 'hello'
  QUEUED
  redis> rpop hi
  QUEUED
  redis> set okay 'done'
  QUEUED
  redis> exec
  1. OK
  2. (error) ERR Operation against a key holding the wrong kind of value
  3. OK
  redis> get okay
  "'done'"
  redis> get hi
  "'hello'"
  redis>

Note that it keeps on processing, even though the second command fails. This also has nothing to do with persistence, as the exhibited behavior will be the same in a fully-alive system and from disk and anything else, because redis maintains a perfect total ordering of operations in its log format and sync behavior.

Reply on news.ycombinator.com