Redis transaktioner (via MULTI/EXEC) grupperer flere kommandoer til at køre atomart — alle sammen uden at andre kommandoer blandes ind. Kombineret med WATCH til optimistisk låsning håndterer de scenarier, der kræver, at flere operationer er konsistente. Redis-transaktioner adskiller sig fra SQL-transaktioner på vigtige måder.
MULTI # start a transaction (begin queuing commands)
SET account:1 100 # QUEUED (not executed yet)
SET account:2 200 # QUEUED
INCR counter # QUEUED
EXEC # execute ALL queued commands atomically (as one unit)
# → all commands run together, with NO other client's commands in between
MULTI starter queueing af kommandoer; EXEC kører dem alle atomart (uden blanding fra andre klienter). DISCARD annullerer en queued transaktion.
# WATCH a key; if it CHANGES before EXEC, the transaction ABORTS (returns nil)
WATCH balance
val = GET balance # read the current value
MULTI
SET balance (val - 100) # modify based on what we read
EXEC # → if "balance" changed since WATCH, EXEC fails (returns nil)
# → retry the whole thing if it failed (optimistic concurrency control)
WATCH giver optimistisk låsning: hvis en watched nøgle ændres af en anden klient før EXEC, afbrydes transaktionen — så du sikkert kan foretage check-then-set-operationer (retry ved konflikt).
⚠️ Redis transactions are NOT like SQL transactions:
✗ NO ROLLBACK — if a command fails at EXEC time, OTHER commands still execute
(errors don't roll back the transaction; Redis doesn't undo). Only syntax errors
before EXEC abort the whole thing.
✓ Atomicity = commands run together without interleaving (isolation), NOT all-or-nothing
with rollback on error.
→ Often Lua SCRIPTS are used instead for complex atomic logic (a script runs atomically).
At forstå Redis-transaktioner er værdifuldt for at udføre flere operationer konsistent, så det er brugbar viden — og at forstå, hvordan de adskiller sig fra SQL-transaktioner, er især vigtig for at undgå ukorrekte antagelser.
Kernefunktionaliteten — MULTI/EXEC gruppering af kommandoer til atomisk udførelse (alle sammen uden at andre klienters kommandoer blandes ind) — løser scenarier, hvor flere operationer må ske som en konsistent enhed.
Mekanismen WATCH giver optimistisk låsning (check-and-set): afbrydelse af transaktionen, hvis en watched nøgle ændrede sig før EXEC, hvilket muliggør sikre check-then-modify-operationer (som at dekrementere en saldo baseret på dens nuværende værdi) med retry ved konflikt — vigtig for korrekte samtidige operationer.
Det vigtigste punkt er at forstå, hvordan Redis-transaktioner adskiller sig fra SQL-transaktioner: Redis har ingen rollback — hvis en kommando mislykkes på EXEC-tidspunkt, kører de andre kommandoer alligevel (Redis fortryder ikke), så "atomicitet" her betyder, at kommandoer køres sammen uden blanding (isolation), IKKE alt-eller-intet med fejlrollback.
Misforståelse af dette (antage SQL-lignende rollback) fører til ukorrekt fejlhåndtering.
At vide, at Lua-scripts ofte bruges i stedet for kompleks atomisk logik (et script køres atomart som en enhed) er værdifuldt.
Da konsistent fleroperations-udførelse og korrekt samtidighed er virkelige behov, og da Redis-transaktioner (MULTI/EXEC med WATCH til optimistisk låsning) adresserer dem, men med vigtige forskelle fra SQL (ingen rollback), der skal forstås, er forståelse af Redis-transaktioner — MULTI/EXEC, WATCH-baseret optimistisk låsning og især no-rollback-skelnen fra SQL — værdifuld, praktisk relevant viden for at bruge Redis korrekt i samtidige scenarier, hvor forståelse af forskellene fra velkendte SQL-transaktioner er lige så vigtig som mekanismen selv.