Preface#
Today, when studying Redis, I found that the transaction feature of Redis cannot be rolled back. That is, when executing a transaction, if a command in the middle fails, it will not roll back to before the transaction, but will continue to execute.
What? What? Then what's the use of transactions if there is no atomicity, no consistency?
According to the information I searched for and thought about, I summarized it a bit, which may not be comprehensive.
Isolation#
Although rollback is not supported, there is still isolation in a concurrent environment. watch can achieve something similar to optimistic locking, and will check for conflicts at the end of exec.
Simple and Efficient#
We found that after learning so many Redis commands, it seems that there are not many commands that will throw errors. Even if you enter the wrong key, it will just return nil. Only when there is a syntax error in your Redis command, or when using keys of the wrong type, will an error be thrown, and these errors should be discovered during development.
So without rollback, Redis internally can be simpler and more efficient, thereby improving performance.
This means that supporting rollback is unnecessary, making Redis simpler and more efficient.