Optimistic concurrency control in DBMS Theory - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is optimistic concurrency control?

Optimistic concurrency control is a method used in databases to handle multiple users trying to change data at the same time. It assumes conflicts are rare and checks for conflicts only when saving changes.

beginner

How does optimistic concurrency control differ from pessimistic concurrency control?

Optimistic concurrency control allows users to work without locking data first, checking for conflicts later. Pessimistic concurrency control locks data before use to prevent conflicts.

beginner

When is optimistic concurrency control most effective?

It works best when conflicts between users are rare, so most changes can be saved without waiting or blocking others.

beginner

What happens if a conflict is detected in optimistic concurrency control?

The system rejects the conflicting change and asks the user to reload the latest data and try again.

intermediate

Name a common technique used to detect conflicts in optimistic concurrency control.

A common technique is to use a version number or timestamp for data. When saving, the system checks if the version has changed since it was read.

What does optimistic concurrency control assume about data conflicts?

A Conflicts are ignored completely

B Conflicts happen often and must be prevented by locking

C No conflicts can ever happen

D Conflicts are rare and checked only at save time

Optimistic concurrency control assumes conflicts are rare and checks for them only when saving changes.

Which of the following is a key feature of optimistic concurrency control?

A Checking for conflicts after changes are made

B Ignoring data versioning

C Preventing all concurrent access

D Locking data before use

Optimistic concurrency control checks for conflicts after changes are made, not before.

What is a common way to detect conflicts in optimistic concurrency control?

A Using data locks

B Using version numbers or timestamps

C Ignoring user changes

D Allowing multiple writes without checks

Version numbers or timestamps help detect if data was changed by someone else before saving.

What happens if a conflict is found during save in optimistic concurrency control?

A The change is saved anyway

B The system blocks all users

C The change is rejected and user must retry

D The system deletes the data

If a conflict is detected, the system rejects the change and asks the user to try again.

Optimistic concurrency control is best suited for which scenario?

A Rare conflict environments

B Single user systems

C High conflict environments

D Systems without data changes

It works best when conflicts are rare, allowing smooth concurrent work.

Explain optimistic concurrency control and how it manages data conflicts.

Think about how users work on data and what happens when they save.

Describe a situation where optimistic concurrency control is better than pessimistic concurrency control.

Consider when locking data might slow things down unnecessarily.

Practice

1. What is the main assumption behind Optimistic Concurrency Control in databases?

easy

A. Transactions always lock data before accessing it

B. Data is never changed during transaction execution

C. All transactions run sequentially without overlap

D. Conflicts between transactions are rare and can be checked at commit time

Solution

1. Step 1: Understand the optimistic concurrency control concept

   It assumes that conflicts between transactions are rare, so it does not lock data during transaction execution.

2. Step 2: Identify when conflicts are checked

   Conflicts are detected only when a transaction tries to commit, by checking if data was changed by others.

3. Final Answer:

   Conflicts between transactions are rare and can be checked at commit time -> Option D

4. Quick Check:

   Optimistic concurrency control = Conflicts checked at commit [OK]

Hint: Remember: optimistic means 'hope no conflict' [OK]

Common Mistakes:

• Thinking data is locked during the whole transaction
• Assuming conflicts are prevented upfront
• Confusing optimistic with pessimistic locking

2. Which of the following is a typical mechanism used in optimistic concurrency control to detect conflicts?

easy

A. Locking rows before update

B. Using version numbers or timestamps on data

C. Serializing all transactions

D. Blocking reads during writes

Solution

1. Step 1: Identify conflict detection methods in optimistic control

   Optimistic concurrency control uses version numbers or timestamps to detect if data was changed by another transaction.

2. Step 2: Eliminate locking and blocking options

   Locking rows or blocking reads are typical of pessimistic control, not optimistic.

3. Final Answer:

   Using version numbers or timestamps on data -> Option B

4. Quick Check:

   Conflict detection = Version/timestamp check [OK]

Hint: Versions or timestamps track changes without locking [OK]

Common Mistakes:

• Confusing locking with optimistic control
• Thinking transactions are serialized automatically
• Assuming reads are blocked during writes

3. Consider a system using optimistic concurrency control with version numbers. If two users read data with version 5, and both try to update it, what happens when the second user tries to commit?

medium

A. Both commits succeed and overwrite each other

B. The second user's commit succeeds without checks

C. The second user's commit fails due to version mismatch

D. The system locks the data to prevent conflicts

Solution

1. Step 1: Understand version checking in optimistic concurrency

   Each update increments the version number. The first user updates version 5 to 6 successfully.

2. Step 2: Check second user's commit attempt

   The second user still has version 5 but data is now version 6, so commit fails due to version mismatch.

3. Final Answer:

   The second user's commit fails due to version mismatch -> Option C

4. Quick Check:

   Version mismatch causes commit failure [OK]

Hint: Second commit fails if version changed since read [OK]

Common Mistakes:

• Assuming both commits succeed
• Thinking system locks data automatically
• Ignoring version number checks

4. A developer implemented optimistic concurrency control but notices that conflicting updates are not detected. What is the most likely error in their approach?

medium

A. They are not checking version or timestamp before commit

B. They are using pessimistic concurrency control

C. They are serializing all transactions

D. They are locking data before reading

Solution

1. Step 1: Identify key step in optimistic concurrency control

   It requires checking the version or timestamp before committing to detect conflicts.

2. Step 2: Analyze the developer's problem

   If conflicts are not detected, likely the version/timestamp check is missing or incorrect.

3. Final Answer:

   They are not checking version or timestamp before commit -> Option A

4. Quick Check:

   Missing version check = No conflict detection [OK]

Hint: Always check version before commit to detect conflicts [OK]

Common Mistakes:

• Confusing locking with optimistic control
• Assuming serialization detects conflicts
• Mixing optimistic and pessimistic methods

5. In a multi-user database system using optimistic concurrency control, how can the system handle a conflict when two users update the same record simultaneously?

hard

A. Automatically merge changes if possible or reject one update

B. Lock the record to prevent simultaneous updates

C. Allow both updates and overwrite the older one silently

D. Queue the second update until the first finishes

Solution

1. Step 1: Understand conflict resolution in optimistic concurrency

   When conflict is detected, the system can try to merge changes or reject one update to maintain data integrity.

2. Step 2: Compare with other concurrency methods

   Locking or queuing are pessimistic methods, not used in optimistic concurrency control.

3. Final Answer:

   Automatically merge changes if possible or reject one update -> Option A

4. Quick Check:

   Conflict resolution = Merge or reject update [OK]

Hint: Optimistic control resolves conflicts by merge or reject [OK]

Common Mistakes:

• Thinking locking is used in optimistic control
• Assuming silent overwrites happen
• Confusing queuing with optimistic concurrency