4 ms·
Are there any good posts on transactions? I've found articles around but nothing very concise that explains the exact behavior of MULTI/EXEC when things go bad.
by giulianob 15y ago
Are there any good posts on transactions? I've found articles around but nothing very concise that explains the exact behavior of MULTI/EXEC when things go bad.
- antirez 15y agobasically MULTI/EXEC is always handled correctly, either everything or nothing is committed to the database memory, RDB file, AOF file, slave, ...
- giulianob 15y agoI 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?
- nbpoole 15y agohttp://redis.io/commands/set http://redis.io/commands/set > Status code reply: always OK since SET can't fail. So, what kind of situation are you envisioning?
- giulianob 15y agoMaybe 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.
- aaronblohowiak 15y agoredis> 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.