Redis transactions (MULTI/EXEC ਰਾਹੀਂ) ਕਈ ਆਦੇਸ਼ਾਂ ਨੂੰ ਗਰੁੱਪ ਕਰਦੀ ਹਨ ਤਾਂ ਜੋ ਉਹ atomically ਚਲਾਏ ਜਾ ਸਕਣ — ਸਾਰੇ ਇਕੱਠੇ ਬਿਨਾ ਹੋਰ ਆਦੇਸ਼ਾਂ ਦੇ ਵਿਚਕਾਰ ਆਉਣ ਦੇ। WATCH ਦੇ ਨਾਲ optimistic locking ਲਈ، ਉਹ ਉਹ ਸਥਿਤੀਆਂ ਨੂੰ ਸੰਭਾਲਦੀ ਹਨ ਜਿਸ ਵਿੱਚ ਕਈ ਓਪਰੇਸ਼ਨ ਇਕਸੁਰ ਹੋਣੀਆਂ ਪੈਣੀਆਂ ਹਨ। 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 ਆਦੇਸ਼ਾਂ ਨੂੰ 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 ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ: ਜੇ ਕਿਸੇ EXEC ਤੋਂ ਪਹਿਲਾਂ ਕਿਸੇ ਹੋਰ client ਦੁਆਰਾ watched ਕੀ ਗਈ key ਨੂੰ ਸੰਸ਼ੋਧਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ 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 ਨੂੰ ਸਮਝਣਾ ਕਈ ਓਪਰੇਸ਼ਨ ਨੂੰ consistently ਪਰਫ਼ਾਰਮ ਕਰਨ ਲਈ ਮੁੱਲਵਾਨ ਹੈ, ਇਸ ਲਈ ਇਹ ਉਪਯੋਗੀ ਗਿਆਨ ਹੈ — ਅਤੇ ਇਹ ਸਮਝ ਕਿ ਉਹ SQL transactions ਤੋਂ ਕਿਵੇਂ ਭਿੰਨ ਹਨ, ਵਿਸ਼ੇਸ਼ ਕਰਕੇ ਗਲਤ ਧਾਰਨਾਵਾਂ ਤੋਂ ਬਚਣ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਮੂਲ ਸਮਰੱਥਾ — MULTI/EXEC ਆਦੇਸ਼ਾਂ ਨੂੰ ਗਰੁੱਪ ਕਰਨਾ atomically ਚਲਾਉਣ ਲਈ (ਸਾਰੇ ਇਕੱਠੇ, ਕਿਸੇ ਹੋਰ client ਦੇ ਆਦੇਸ਼ਾਂ ਦੇ ਬਿਨਾ interleaving ਦੇ) — ਉਹ ਸਥਿਤੀਆਂ ਨੂੰ ਸੰਭਾਲਦੀ ਹੈ ਜਿਥੇ ਕਈ ਓਪਰੇਸ਼ਨ ਇਕ ਇਕਸਾਰ ਯੂਨਿਟ ਵਜੋਂ ਵਾਪਰਨੀ ਚਾਹੀਦੀ ਹੈ।
WATCH ਮਕੈਨਿਜ਼ਮ optimistic locking ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ (check-and-set): EXEC ਤੋਂ ਪਹਿਲਾਂ ਜੇ ਕੋਈ watched key ਬਦਲੀ, ਤਾਂ transaction abort ਕਰ ਦਿੰਦਾ ਹੈ، ਸੁਰੱਖਿਅਤ check-then-modify operations ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ (ਜਿਵੇਂ ਇਸ ਦੀ ਵਰਤਮਾਨ ਮੁੱਲ ਦੇ ਆਧਾਰ 'ਤੇ ਬੈਲੇਂਸ ਘਟਾਉਣਾ) conflict ਉੱਤੇ retry ਨਾਲ — correct concurrent operations ਲਈ ਮਹੱਤਵਪੂਰਨ।
ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਪੱਖ ਇਹ ਸਮਝ ਹੈ ਕਿ Redis transactions SQL transactions ਤੋਂ ਕਿਵੇਂ ਵੱਖ ਹਨ: Redis ਕੋਲ ਕੋਈ rollback ਨਹੀਂ — ਜੇ EXEC ਸਮੇ ਕਾਈ ਆਦੇਸ਼ fail ਹੋਵੇ, ਤਾਂ ਹੋਰ ਆਦੇਸ਼ ਫਿਰ ਵੀ ਚਲਦੇ ਹਨ (Redis ਉਲਟ ਨਹੀਂ ਕਰਦਾ), ਇਸ ਲਈ "atomicity" ਇੱਥੇ ਮਤਲਬ ਹੈ ਆਦੇਸ਼ ਨਾਲ-ਨਾਲ ਚਲਦੇ ਹਨ ਬਿਨਾ interleaving (isolation), ਆਲ-ਆਰ-ਨਥਿੰਗ ਨਹੀਂ error rollback ਨਾਲ।
ਇਸ ਨੂੰ ਗਲਤ ਸਮਝਣਾ (SQL-ਵਾਂਗ rollback ਮੰਨਣਾ) ਗਲਤ error handling ਕਾਰਨ ਬਣਦਾ ਹੈ।
ik ਹੋਣਾ ਕਿ Lua scripts ਅਕਸਰ complex atomic logic ਲਈ ਬਜਾਏ ਵਰਤੇ ਜਾਂਦੇ ਹਨ (ਇੱਕ script atomically ਯੂਨਿਟ ਦੇ ਰੂਪ ਵਿੱਚ ਚਲਦਾ ਹੈ) ਉਪਯੋਗੀ ਹੈ।
ਕਿਉਂਕਿ consistent multi-operation execution ਅਤੇ correct concurrency ਅਸਲ ਜ਼ਰੂਰਤਾਂ ਹਨ, ਅਤੇ ਕਿਉਂਕਿ Redis transactions (optimistic locking ਲਈ WATCH ਨਾਲ MULTI/EXEC) ਉਹਨਾਂ ਨੂੰ ਸੰਭਾਲਦੀ ਹੈ ਪਰ SQL ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਅੰਤਰ ਨਾਲ (ਕੋਈ rollback ਨਹੀਂ) ਜੋ ਸਮਝਣੀ ਚਾਹੀਦੀ ਹੈ, Redis transactions ਨੂੰ ਸਮਝਣਾ — MULTI/EXEC, WATCH-ਆਧਾਰਤ optimistic locking, ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ SQL ਤੋਂ no-rollback distinction — Redis ਨੂੰ concurrent scenarios ਵਿੱਚ ਠੀਕ ਤਰ੍ਹਾਂ ਵਰਤਣ ਲਈ ਮੁੱਲਵਾਨ, practically-relevant ਗਿਆਨ ਹੈ, ਜਿੱਥੇ familiar SQL transactions ਤੋਂ ਅੰਤਰ ਨੂੰ ਸਮਝਣਾ mechanism ਆਪ ਜਿੰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ।