WATCH for optimistic locking in Redis - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to start watching a key for optimistic locking.

Redis

redis_client.[1]('mykey')

Drag options to blanks, or click blank then click option'

Amulti

Bwatch

Cexec

Dunwatch

Attempts:

3 left

💡 Hint

Common Mistakes

Using MULTI instead of WATCH to monitor keys.

Using EXEC before WATCH.

Using UNWATCH to start watching keys.

The watch command tells Redis to monitor the key for changes before executing a transaction.

2fill in blank

medium

Complete the code to start a transaction after watching keys.

Redis

redis_client.[1]()

Drag options to blanks, or click blank then click option'

Amulti

Bwatch

Cexec

Dunwatch

Attempts:

3 left

💡 Hint

Common Mistakes

Using WATCH instead of MULTI to start a transaction.

Using EXEC before MULTI.

Using UNWATCH to start a transaction.

The multi command starts a transaction block in Redis after watching keys.

3fill in blank

hard

Fix the error in the code to execute the transaction and release the watch.

Redis

redis_client.[1]()

Drag options to blanks, or click blank then click option'

Amulti

Bwatch

Cunwatch

Dexec

Attempts:

3 left

💡 Hint

Common Mistakes

Using MULTI instead of EXEC to run the transaction.

Using WATCH to execute commands.

Using UNWATCH before executing the transaction.

The exec command executes all queued commands in the transaction and releases the watch.

4fill in blank

hard

Fill both blanks to unwatch keys and discard the transaction.

Redis

redis_client.[1]()
redis_client.[2]()

Drag options to blanks, or click blank then click option'

Aunwatch

Bdiscard

Cexec

Dmulti

Attempts:

3 left

💡 Hint

Common Mistakes

Using EXEC instead of DISCARD to cancel the transaction.

Using MULTI instead of UNWATCH to stop watching keys.

Not calling UNWATCH before DISCARD.

UNWATCH stops watching keys without executing the transaction, and DISCARD cancels the transaction queue.

5fill in blank

hard

Fill all three blanks to watch a key, start a transaction, and execute it.

Redis

redis_client.[1]('counter')
redis_client.[2]()
redis_client.[3]()

Drag options to blanks, or click blank then click option'

Awatch

Bmulti

Cexec

Dunwatch

Attempts:

3 left

💡 Hint

Common Mistakes

Skipping WATCH before MULTI.

Using UNWATCH instead of EXEC to run the transaction.

Calling EXEC before MULTI.

First, WATCH monitors the key. Then, MULTI starts the transaction. Finally, EXEC runs the queued commands.

Practice

1. What is the main purpose of the WATCH command in Redis optimistic locking?

easy

A. To monitor keys for changes before executing a transaction

B. To lock keys permanently for exclusive access

C. To delete keys automatically after a timeout

D. To create backups of keys before modification

Solution

1. Step 1: Understand the role of WATCH in Redis

   WATCH is used to monitor keys for any changes before a transaction starts.

2. Step 2: Identify what happens if keys change

   If any watched key changes before EXEC, the transaction is canceled to avoid conflicts.

3. Final Answer:

   To monitor keys for changes before executing a transaction -> Option A

4. Quick Check:

   WATCH detects key changes before transaction [OK]

Hint: WATCH checks keys before transaction to avoid conflicts [OK]

Common Mistakes:

• Thinking WATCH locks keys permanently
• Assuming WATCH deletes keys
• Believing WATCH creates backups

2. Which of the following is the correct sequence of Redis commands to safely update a key counter using optimistic locking?

easy

A. MULTI, WATCH counter, INCR counter, EXEC

B. WATCH counter, MULTI, INCR counter, EXEC

C. WATCH counter, INCR counter, MULTI, EXEC

D. INCR counter, WATCH counter, MULTI, EXEC

Solution

1. Step 1: Identify correct order for optimistic locking

   You must first WATCH the key to monitor changes, then start MULTI for transaction.

2. Step 2: Confirm command order

   The correct order is WATCH counter, then MULTI, then commands like INCR, finally EXEC.

3. Final Answer:

   WATCH counter, MULTI, INCR counter, EXEC -> Option B

4. Quick Check:

   WATCH before MULTI for optimistic locking [OK]

Hint: Always WATCH before MULTI to start transaction safely [OK]

Common Mistakes:

• Starting MULTI before WATCH
• Running commands before MULTI
• Not using EXEC at the end

3. Consider this Redis transaction sequence:

WATCH balance
MULTI
INCR balance
EXEC

If another client modifies balance after WATCH but before EXEC, what will be the result of EXEC?

medium

A. EXEC will fail and return null

B. EXEC will succeed and increment balance

C. EXEC will throw a syntax error

D. EXEC will retry automatically

Solution

1. Step 1: Understand WATCH behavior on key change

   If a watched key changes before EXEC, the transaction is aborted to prevent conflicts.

2. Step 2: Identify EXEC result when aborting

   When aborted, EXEC returns null (or nil) indicating the transaction did not run.

3. Final Answer:

   EXEC will fail and return null -> Option A

4. Quick Check:

   Key changed after WATCH causes EXEC to return null [OK]

Hint: If watched key changes, EXEC returns null, no update done [OK]

Common Mistakes:

• Assuming EXEC still increments key
• Expecting syntax error on EXEC
• Thinking EXEC retries automatically

4. You wrote this Redis code:

WATCH stock
MULTI
DECR stock
EXEC

But sometimes the stock count is not decremented even though no errors occur. What is the most likely cause?

medium

A. EXEC command was missing

B. The DECR command syntax is incorrect

C. The stock key was modified by another client after WATCH

D. WATCH does not support DECR command

Solution

1. Step 1: Analyze why stock is not decremented

   If another client changes the watched key after WATCH, EXEC aborts the transaction silently.

2. Step 2: Confirm command correctness

   DECR syntax is correct and EXEC is present, so no syntax errors.

3. Final Answer:

   The stock key was modified by another client after WATCH -> Option C

4. Quick Check:

   Concurrent key change aborts transaction silently [OK]

Hint: Concurrent changes abort EXEC silently, no decrement done [OK]

Common Mistakes:

• Blaming DECR syntax
• Forgetting EXEC command
• Thinking WATCH blocks commands

5. You want to safely increment a shared counter only if it is less than 10 using Redis optimistic locking. Which code snippet correctly implements this logic?

hard

A. WATCH counter
if val < 10:
val = GET counter
MULTI
INCR counter
EXEC

B. MULTI
WATCH counter
val = GET counter
if val < 10:
INCR counter
EXEC

C. WATCH counter
MULTI
val = GET counter
if val < 10:
INCR counter
EXEC

D. WATCH counter
val = GET counter
MULTI
if val < 10:
INCR counter
EXEC

Solution

1. Step 1: Understand optimistic locking with conditional logic

   You must WATCH the key, then GET its value before starting MULTI to ensure value is current.

2. Step 2: Confirm correct command order

   WATCH first, then GET value, then MULTI, then conditionally INCR, finally EXEC.

3. Final Answer:

   WATCH counter val = GET counter MULTI if val < 10: INCR counter EXEC -> Option D

4. Quick Check:

   GET before MULTI after WATCH ensures correct conditional update [OK]

Hint: GET value after WATCH but before MULTI for safe conditional update [OK]

Common Mistakes:

• Starting MULTI before GET
• Getting value after MULTI
• Not watching key before GET