CODEWITHSUNDEEP
redis
Lucky Lam
Lucky Lam

Reputation: 145

Redis transaction atomically

I'm new to Redis and while reading its transaction on the official site, I'm so confused at one thing.

  1. It says

Either all of the commands or none are processed, so a Redis transaction is also atomic.

  1. Then it says

even when a command fails, all the other commands in the queue are processed –

So it opposes to one another, doesn't it?

Upvotes: 4

Views: 4862

Answers (4)

riki
riki

Reputation: 41

I think the definition of redis transaction being "atomically" is somewhat like "linearly".

Referring to https://en.wikipedia.org/wiki/Linearizability

This property of occurring instantaneously, or indivisibly, leads to the use of the term atomic as an alternative to the longer "linearizable".

In that case, redis is ensuring the execution of the transaction is not interfered (or indivisible) by other commands, and commands within the transaction can be executed one by one linearly. On why redis allows partial success in transaction, this should be a topic about the design around "What about rollbacks", but not atomicity.

Upvotes: 0

Murphy Ng
Murphy Ng

Reputation: 562

Simply put, Redis TRANSACTION owns any feature a transaction should have except that it cannot rolled back during a failure. Because the redis's Author think the rollback function in a failure is unnecessary, a failure can only be caused by programming mistakes.

Maybe I should mention you that, redis transaction achieved by multi series command is NOT a good choice, because it is kind of a obselete function(the author think Lua is a much better way and make multi totally unnecessary). Using redis Lua is much better!

Quote from redis author:

A Redis script is transactional by definition, so everything you can do with a Redis transaction, you can also do with a script, and usually the script will be both simpler and faster. This duplication is due to the fact that scripting was introduced in Redis 2.6 while transactions already existed long before. However we are unlikely to remove the support for transactions in the short time because it seems semantically opportune that even without resorting to Redis scripting it is still possible to avoid race conditions, especially since the implementation complexity of Redis transactions is minimal. However it is not impossible that in a non immediate future we'll see that the whole user base is just using scripts. If this happens we may deprecate and finally remove transactions.

You should have a good look at the Lua chapter of Redis Documentation. It's indeed a much better and powerful solution, except requires you know some Lua.

reply if you need to know more

Upvotes: 1

The Real Bill
The Real Bill

Reputation: 15773

There is a difference between a processed command and a failure. In SQL if any command fails the entire transaction is rolled back and it is as if none of them were done. In redis, a command failure does not prevent the other commands from processing or having been processed, with each failing or succeeding independently.

So if you increment a counter, then try to set a different key to a value and it fails, the increment still happened and isn't rolled back. Thus all commands were processed even though one failed.

Upvotes: 3

sisoft
sisoft

Reputation: 973

It's about a different things. Redis have pipelines - client can send many commands to redis at once. Inside of pipeline batch can be transactions. And when transaction fails all commands inside a transaction will be discarded, but any pipelined (queued) commands after EXEC command will be executed anyway.

For more information see http://redis.io/topics/pipelining and http://redis.io/topics/transactions.

Upvotes: 5

Related Questions