Redis transactions (MULTI/EXEC کے ذریعے) متعدد commands کو atomically execute کرنے کے لیے گروپ کرتے ہیں — سب کچھ اکٹھا بغیر دوسری commands کے interleave ہوئے۔ WATCH کے ساتھ optimistic locking کے لیے، وہ scenarios کو سنبھالتے ہیں جہاں متعدد operations مطابقت پذیر ہونے کی ضرورت ہو۔ 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 کو queueing شروع کرتا ہے؛ EXEC انہیں سب atomically چلاتا ہے (دوسری clients سے کوئی interleaving نہیں)۔ 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 دوسری client کے ذریعے EXEC سے پہلے تبدیل ہو، 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 سمجھنا متعدد operations کو مطابقت سے انجام دینے کے لیے قیمتی ہے، تو یہ مفید علم ہے — اور یہ سمجھنا کہ وہ SQL transactions سے کیسے مختلف ہیں خاص طور پر غلط مفروضات سے بچنے کے لیے اہم ہے۔
بنیادی صلاحیت — MULTI/EXEC commands کو grouping کرتے ہوئے انہیں atomically execute کریں (سب کچھ اکٹھا، دوسری client کی کوئی commands interleave نہ ہوں) — ایسے scenarios کو حل کرتی ہے جہاں متعدد operations ایک مطابقت پذیر unit کے طور پر واقع ہونے چاہیں۔
WATCH mechanism optimistic locking فراہم کرتا ہے (check-and-set): اگر watched key EXEC سے پہلے بدل گئی تو transaction abort کرتے ہوئے، safe check-then-modify operations کو فعال کرتے ہوئے (جیسے موجودہ value کی بنیاد پر balance میں کمی) conflict پر retry کے ساتھ — صحیح concurrent operations کے لیے اہم۔
سب سے اہم نکتہ یہ سمجھنا ہے کہ Redis transactions SQL transactions سے کیسے مختلف ہیں: Redis میں کوئی rollback نہیں — اگر EXEC وقت کوئی command ناکام ہو، دوسری commands پھر بھی execute ہوتی ہیں (Redis undo نہیں کرتا)، تو یہاں "atomicity" کا مطلب ہے commands اکٹھا چلتی ہیں بغیر interleaving (isolation)، all-or-nothing نہیں error rollback کے ساتھ۔
اس کو غلط سمجھنا (SQL جیسی rollback فرض کرنا) غلط error handling کی طرف لے جاتا ہے۔
یہ جاننا کہ Lua scripts اکثر پیچیدہ atomic logic کے لیے استعمال ہوتے ہیں (ایک script atomically ایک unit کے طور پر execute ہوتا ہے) قیمتی ہے۔
چونکہ مطابقت پذیر multi-operation execution اور صحیح concurrency حقیقی ضروریات ہیں، اور چونکہ Redis transactions (WATCH کے ساتھ optimistic locking کے لیے MULTI/EXEC) انہیں حل کرتے ہیں لیکن SQL سے اہم اختلافات (کوئی rollback نہیں) کے ساتھ جو سمجھے جانے چاہیں، Redis transactions سمجھنا — MULTI/EXEC، WATCH-based optimistic locking، اور خاص طور پر SQL سے no-rollback distinction — قیمتی، عملی طور پر متعلقہ علم ہے Redis کو concurrent scenarios میں صحیح طریقے سے استعمال کرنے کے لیے، جہاں familiar SQL transactions سے اختلافات سمجھنا میکانزم خود جتنا اہم ہے۔