ALL COVERED TOPICS

NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter

NAVIGATE MAIN CATEGORIES

Close
Monday, 3 May 2010
‹ Back

Redis MULTI/EXEC/DISCARD and Transactions

About:
,

There seems to be some confusion[1] about the new Redis command: MULTI/EXEC/DISCARD which is confused for transactional support. While there are some similarities, let’s take a quick look at what MULTI/EXEC/DISCARD really is [2]:

  • the commands inside a MULTI/EXEC are batched together and executed at once. Basically none of the commands is executed until the EXEC is emitted. In other words, you can say that the commands in a MULTI/EXEC block are serialized and executed sequentially. This part of MULTI/EXEC/DISCARD is indeed similar to transaction semantics and can be considered to be the Atomic part
  • there is also a guarantee that no other commands will be executed in the middle of a MULTI/EXEC (nb right now I’m not sure this is a guarantee of this command implementation or just a consequence of Redis being single-threaded). Anyways, this guarantee could be translated as the Isolation and Consistent parts of a transaction

But here is where the similarities are ending. As you probably know already there is no Durability guarantee in Redis, except the case you configured Redis to use the Append Only File persistence with sync every command which will slow down Redis quite a bit.

But even if we leave aside the Durability aspect, there is another interesting difference:

even when a command will raise an error, all the other commands in the queue will be processed. Redis will NOT stop the processing of commands once an error is found.

And I’d say this is the fundamental difference between Redis MULTI/EXEC/DISCARD and transaction semantics. DISCARD doesn’t seem to be equivalent to ROLLBACK[3] and that means that both Isolation and Consistency guarantees are broken.

In conclusion, I’d say that MULTI/EXEC/DISCARD while being a very useful and interesting addition, is just a batched serialized execution of a set of commands that partially covers the semantics of ACID transactions.

References

  • [1] It my be the case I’m the one confused though. (↩)
  • [2] My comments are based on the documentation for MULTI/EXEC/DISCARD found ☞ here and a conversation I’ve had on Twitter (↩)
  • [3] According to the documentation (nb the important part IMO is “no commands will be executed”, pointing out that you either end a MULTI block with DISCARD or once EXEC is called you’ll have to manually rollback changes to gain real transaction semantics): (↩)

    DISCARD can be used in order to abort a transaction. No command will be executed, and the state of the client is again the normal one, outside of a transaction.