Understanding Redis Transactions: Concepts, Limitations, and Practical Demonstrations

For developers familiar with relational databases, the term "transaction" is well known; it groups a set of operations so that they are treated as a single unit, guaranteeing ACID properties (Atomicity, Consistency, Isolation, Durability). Redis transactions differ: they do not provide atomicity or isolation, functioning instead as a simple command queue.

When a transaction is started with MULTI, subsequent commands are queued (the client receives QUEUED) but not executed immediately. The queued commands are later executed in order when EXEC is issued.

If any command in the queue contains a syntax error or other compile‑time error, Redis aborts the entire transaction and returns an error before execution. Since Redis 2.6.5, the server records queuing failures and rejects the transaction at EXEC time.

Runtime errors (e.g., trying to INCR a non‑integer value) do not abort the transaction; the offending command returns an error while the remaining commands continue to run.

Transactions can be cancelled explicitly with DISCARD, by issuing an invalid command followed by EXEC, or simply by closing the client connection.

Redis does not support rollback, but it offers an optimistic‑locking mechanism via the WATCH command. By watching one or more keys before starting a transaction, the transaction will be aborted (returning nil) if any watched key is modified by another client before EXEC is called.

Below are representative command‑line demonstrations.

127.0.0.1:6379> MULTI
OK

Queueing several commands:

127.0.0.1:6379> MSET k1 v1 k2 v2 k3 v3
QUEUED
127.0.0.1:6379> SET ktest test
QUEUED
127.0.0.1:6379> GET k3
QUEUED

Execute the transaction:

127.0.0.1:6379> EXEC
1) OK
2) OK
3) "v3"

Example of a runtime error (incrementing a non‑integer key):

127.0.0.1:6379> SET k1 v1
QUEUED
127.0.0.1:6379> GET k1
QUEUED
127.0.0.1:6379> INCR k1
QUEUED
127.0.0.1:6379> GET k1
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) "v1"
3) (error) ERR value is not an integer or out of range
4) "v1"

Cancel a transaction using DISCARD:

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET k2 v2
QUEUED
127.0.0.1:6379> DISCARD
OK

Optimistic lock with WATCH:

# Client 1
127.0.0.1:6379> SET money 100
OK
127.0.0.1:6379> WATCH money
OK
127.0.0.1:6379> MULTI
OK
# Client 2 modifies the key
127.0.0.1:6379> SET money 1000
OK
# Back to Client 1
127.0.0.1:6379> SET money 20
QUEUED
127.0.0.1:6379> EXEC
(nil)   # Transaction aborted because watched key changed

In summary, Redis transactions provide a lightweight way to batch commands, but they lack true atomicity and isolation; developers must handle errors explicitly and can use WATCH for optimistic concurrency control.