Transactional support is really a cool feature.

To clarify

1. transactions are not supported with the append only mode? Or will Redis, when it restarts, essentially rollback those that weren't EXEC'd.

2. When a MULTI command is received, no other commands are processed? Is that how Redis works in general for other commands as well?

All seems great, except that when an error is raised the other changes still complete! Surely this should discard the other changes since otherwise it isn't really transactional...other connections might read an inconsistent state.

Macros, not Transactions

I agree with tsalfield.

To truly be called "transactions" the commands between a MULTI and EXEC should not only all be executed or none executed but rather all should succeed or none are executed. Yes, that's more difficult. But, I cannot see how this MULTI..EXEC is useful for the true meaning of transactions.

What do you think?

"...A transaction is said to be atomic if when one part of the transaction fails, the entire transaction fails and database state is left unchanged. It is CRITICAL that the database management system maintains the atomic nature of transactions in spite of any application, DBMS, operating system or hardware failure."

The MultiExecCommand does not follow this principle.

I think you are missing the point about MULTI/EXEC, that is, a Redis command only fails on syntax error or type mismatch. That is, in code without errors the transaction will either be executed as whole or nothing. Still it is true that if there are programming erros like using a list command against a set, or a syntax error, only the sane commands will be performed and the others instead will fail, but it's very hard for this to happen in production.

On the other hand since roll back is not needed, the performance of Redis MULTI/EXEC is very good.

"Thanks to WATCH we area able to model the problem very well:"

s/area/are/

More information about the return values would be helpful.

Sounds like: MULTI returns status DISCARD returns status WATCH returns status UNWATCH returns status

Correct?

Hi, I got confused by the relationship between MULTI/EXEC and AOF. In this document you say:

"An exception to this rule is when the Append Only File is enabled: every command that is part of a Redis transaction will log in the AOF as long as the operation is completed, so if the Redis server crashes or is killed by the system administrator in some hard way it is possible that only a partial number of operations are registered."

While on the redis cookbook (http://rediscookbook.org/pipeline_multiple_commands.html) the author states: "Now, M/E does not provide complete 'transactions' -- at least not in the ordinary sense -- since it does not include 'rollback' functionality. Consider the following situation. You create a relatively large M/E queue (say, with 200 commands) and run EXEC. Before all the queued commands are executed, the server crashes, or perhaps it runs out of memory -- let's say that happens at command #148. The first 148 commands are indeed executed, but the rest are not.

Indeed, M/E is only an 'all or nothing' operation before the EXEC command is run (that is, during queueing) -- not during the execution.

Redis does provide an interesting way to deal with issue: the familiar Append-Only File. In the upcoming version of Redis, the commands in the queue are only written to the AOF upon successful completion of the EXEC command. So if your server crashes mid-EXEC, you can rebuild state according to the previous, pre-EXEC state"

So, is it possible to update the AOF only in case of complete execution of the queue ? In my opinion, as the concept of MULTI/EXEC is all or nothing, the same should be enforced on data saving level, to give the oppurtunity of restoring the system state at PRE-EXEC time (in case of incomplete MULTI esecution).