Redis transactions (MULTI/EXEC ద్వారా) బహుళ commands లను atomically నిర్వహించడానికి సమూహం చేస్తాయి — అన్నిటిని కలిసి ఇతర commands ఇంటర్లీవ్ చేయకుండా. WATCH తో optimistic locking కోసం కలిసి, అవి బహుళ operations నిరూపితమైన రూపంలో ఉండవలసిన scenarios ను నిర్వహిస్తాయి. Redis transactions SQL transactions నుండి ముఖ్యమైన మార్గాలలో భిన్నంగా ఉన్నాయి.
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 commands ను queuing చేయడం ప్రారంభిస్తుంది; EXEC వాటి అన్నిటిని atomically నిర్వహిస్తుంది (ఇతర clients నుండి ఇంటర్లీవ్ లేదు). DISCARD ఒక queued transaction ను రద్దు చేస్తుంది.
# 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 optimistic locking ను అందిస్తుంది: ఒక watched key EXEC నుండి ముందు ఇతర client ద్వారా సవరించబడితే, transaction abort చేస్తుంది — మీరు safely check-then-set operations (conflict పై retry) చేయడానికి అనుమతిస్తుంది.
⚠️ 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).
Redis transactions ను అర్థం చేసుకోవడం multiple operations ను consistently నిర్వహించడానికి విలువైనది, కాబట్టి ఇది ఉపయోగకరమైన జ్ఞానం — మరియు అవి SQL transactions నుండి ఎలా భిన్నంగా ఉన్నాయో అర్థం చేసుకోవడం తప్పు assumptions ను నివారించడానికి ముఖ్యమైనది.
కోర్ సామర్థ్యం — MULTI/EXEC commands ను atomically నిర్వహించడానికి సమూహం చేస్తుంది (అన్నిటిని కలిసి, ఇతర client's commands ఇంటర్లీవ్ చేయకుండా) — బహుళ operations ఒక నిరూపితమైన యూనిట్గా జరగవలసిన scenarios ను పరిష్కరిస్తుంది.
WATCH mechanism optimistic locking (check-and-set) ను అందిస్తుంది: EXEC నుండి ముందు ఒక watched key మార్పైతే transaction ను abort చేస్తుంది, safe check-then-modify operations (like balance ను దాని current value ఆధారంగా decrementing) conflict పై retry తో అనుమతిస్తుంది — సరైన concurrent operations కోసం ముఖ్యమైనది.
అత్యంత క్రిటికల్ పాయింట్ Redis transactions SQL transactions నుండి ఎలా భిన్నంగా ఉన్నాయో అర్థం చేసుకోవడం: Redis కు no rollback ఉంది — ఒక command EXEC సమయంలో విఫలమైతే, ఇతర commands ఇప్పటికీ నిర్వహిస్తారు (Redis ను undo చేయదు), కాబట్టి "atomicity" ఇక్కడ means commands together without interleaving (isolation) నిర్వహిస్తారు, ALL-or-NOTHING with error rollback కాదు.
ఈ misunderstanding (SQL-like rollback assuming) తప్పు error handling కు దారితీస్తుంది.
Lua scripts తరచుగా సంక్లిష్ట atomic logic కోసం బదులుగా ఉపయోగించబడతాయి (ఒక script atomically ఒక యూనిట్గా నిర్వహిస్తుంది) ఈ విషయం knowing విలువైనది.
సంపూర్ణ multi-operation execution నిరూపితం మరియు సరైన concurrency నిజమైన needs నుండి, మరియు Redis transactions (optimistic locking కోసం WATCH తో MULTI/EXEC) వాటిని చేరుకుంటాయి కానీ SQL (no rollback) నుండి ముఖ్యమైన భిన్నతలతో అర్థం చేసుకోవలసి ఉంది, understanding Redis transactions — MULTI/EXEC, WATCH-based optimistic locking, మరియు ముఖ్యంగా SQL నుండి no-rollback distinction — Redis ను correctly concurrent scenarios లో ఉపయోగించడానికి విలువైన, practically-relevant జ్ఞానం, ఇక్కడ familiar SQL transactions నుండి భిన్నతలను అర్థం చేసుకోవడం mechanism నిজుగా చేసేటప్పుడు ముఖ్యమైనది.