Transaction isolation levels in SQL - Mini Project: Build & Apply

Understanding Transaction Isolation Levels in SQL

📖 Scenario: You are working as a junior database administrator for a small online bookstore. Your manager wants you to demonstrate how different transaction isolation levels affect data consistency when multiple users access the database simultaneously.

🎯 Goal: Build a simple SQL script that sets up a books table, inserts sample data, and shows how to set and use different transaction isolation levels to control concurrent access.

📋 What You'll Learn

Create a books table with columns id, title, and stock

Insert three specific book records into the books table

Declare a variable to hold the desired transaction isolation level

Write a SQL command to set the transaction isolation level using the declared variable

Write a simple transaction block that selects all books within the set isolation level

💡 Why This Matters

🌍 Real World

Transaction isolation levels are crucial in real-world databases to control how multiple users see and modify data at the same time, preventing errors like dirty reads or lost updates.

💼 Career

Understanding and configuring transaction isolation levels is a key skill for database administrators and backend developers to ensure data consistency and application reliability.

1

Create the books table and insert data

Write SQL commands to create a table called books with columns id (integer primary key), title (text), and stock (integer). Then insert these three rows exactly: (1, 'Learn SQL', 10), (2, 'Mastering Databases', 5), and (3, 'SQL for Beginners', 8).

SQL

-- Create the books table and insert three rows
-- Your code here

Hint

Use CREATE TABLE to define the table and INSERT INTO to add rows.

2

Declare a variable for the transaction isolation level

Declare a variable called isolation_level and set it to the string 'READ COMMITTED' to represent the transaction isolation level.

SQL

CREATE TABLE books (
    id INT PRIMARY KEY,
    title TEXT,
    stock INT
);

INSERT INTO books (id, title, stock) VALUES
(1, 'Learn SQL', 10),
(2, 'Mastering Databases', 5),
(3, 'SQL for Beginners', 8);

-- Declare the isolation_level variable
-- Your code here

Hint

Use DECLARE to create a variable and assign the string 'READ COMMITTED'.

3

Set the transaction isolation level using the variable

Write a SQL command to set the transaction isolation level using the variable @isolation_level. Use the syntax SET TRANSACTION ISOLATION LEVEL followed by the variable value.

SQL

CREATE TABLE books (
    id INT PRIMARY KEY,
    title TEXT,
    stock INT
);

INSERT INTO books (id, title, stock) VALUES
(1, 'Learn SQL', 10),
(2, 'Mastering Databases', 5),
(3, 'SQL for Beginners', 8);

DECLARE @isolation_level VARCHAR(20) = 'READ COMMITTED';

-- Set the transaction isolation level using @isolation_level
-- Your code here

Hint

Use dynamic SQL execution with EXEC to set the isolation level using the variable.

4

Write a transaction block to select all books

Write a transaction block that begins with BEGIN TRANSACTION, selects all rows from the books table, and ends with COMMIT. This will run under the set transaction isolation level.

SQL

CREATE TABLE books (
    id INT PRIMARY KEY,
    title TEXT,
    stock INT
);

INSERT INTO books (id, title, stock) VALUES
(1, 'Learn SQL', 10),
(2, 'Mastering Databases', 5),
(3, 'SQL for Beginners', 8);

DECLARE @isolation_level VARCHAR(20) = 'READ COMMITTED';

EXEC('SET TRANSACTION ISOLATION LEVEL ' + @isolation_level);

-- Begin transaction, select all books, and commit
-- Your code here

Hint

Use BEGIN TRANSACTION to start, then SELECT * FROM books, and finish with COMMIT.

Practice

1. Which transaction isolation level allows a transaction to see uncommitted changes made by other transactions?

easy

A. READ UNCOMMITTED

B. READ COMMITTED

C. REPEATABLE READ

D. SERIALIZABLE

Solution

1. Step 1: Understand isolation levels and identify the matching one

   READ UNCOMMITTED is the lowest isolation level allowing dirty reads (seeing uncommitted changes from other transactions).

2. Final Answer:

   READ UNCOMMITTED -> Option A

3. Quick Check:

   Dirty reads = READ UNCOMMITTED [OK]

Hint: Lowest level allows dirty reads: READ UNCOMMITTED [OK]

Common Mistakes:

• Confusing READ COMMITTED with allowing dirty reads
• Thinking SERIALIZABLE allows uncommitted reads
• Mixing REPEATABLE READ with dirty read behavior

2. Which of the following is the correct SQL syntax to set the transaction isolation level to SERIALIZABLE?

easy

A. SET ISOLATION LEVEL TRANSACTION SERIALIZABLE;

B. SET TRANSACTION LEVEL ISOLATION SERIALIZABLE;

C. SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

D. SET SERIALIZABLE ISOLATION LEVEL;

Solution

1. Step 1: Recall and match the correct SQL syntax

   The standard syntax is SET TRANSACTION ISOLATION LEVEL [level]; Only SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; matches exactly.

2. Final Answer:

   SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; -> Option C

3. Quick Check:

   Correct syntax = SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; [OK]

Hint: Remember: SET TRANSACTION ISOLATION LEVEL [level]; [OK]

Common Mistakes:

• Swapping keywords order incorrectly
• Omitting 'TRANSACTION' keyword
• Using non-standard syntax

3. Consider two transactions T1 and T2 running concurrently. T1 reads a row, then T2 updates and commits that row. If the isolation level is REPEATABLE READ, what will T1 see when it reads the same row again?

medium

A. The updated value committed by T2

B. The original value before T2's update

C. An error due to concurrent update

D. A partially updated value

Solution

1. Step 1: Understand REPEATABLE READ and apply to scenario

   REPEATABLE READ ensures a transaction sees the same data on repeated reads of the same row. T1's second read sees the original value despite T2's committed update.

2. Final Answer:

   The original value before T2's update -> Option B

3. Quick Check:

   REPEATABLE READ prevents non-repeatable reads = The original value before T2's update [OK]

Hint: REPEATABLE READ keeps data stable during transaction [OK]

Common Mistakes:

• Assuming T1 sees T2's committed update immediately
• Confusing REPEATABLE READ with READ COMMITTED
• Thinking it causes errors on concurrent updates

4. You wrote this SQL command to set the isolation level but get an error:
SET TRANSACTION LEVEL ISOLATION READ COMMITTED;
What is the error in this statement?

medium

A. The statement is correct; error is elsewhere.

B. 'TRANSACTION' keyword is missing.

C. 'READ COMMITTED' is not a valid isolation level.

D. The order of 'LEVEL' and 'ISOLATION' is incorrect.

Solution

1. Step 1: Check correct syntax and identify the error

   Correct syntax is SET TRANSACTION ISOLATION LEVEL [level]; The given statement swaps 'LEVEL' and 'ISOLATION', causing a syntax error.

2. Final Answer:

   The order of 'LEVEL' and 'ISOLATION' is incorrect. -> Option D

3. Quick Check:

   Syntax order matters = The order of 'LEVEL' and 'ISOLATION' is incorrect. [OK]

Hint: Remember correct keyword order: ISOLATION LEVEL [OK]

Common Mistakes:

• Swapping 'LEVEL' and 'ISOLATION' keywords
• Assuming 'READ COMMITTED' is invalid
• Missing semicolon causing error

5. A bank application uses SERIALIZABLE isolation level to prevent anomalies. However, users report frequent transaction failures due to serialization errors. What is the best approach to reduce these errors while maintaining data accuracy?

hard

A. Keep SERIALIZABLE and retry failed transactions automatically

B. Disable transactions to improve performance

C. Switch to READ UNCOMMITTED to avoid errors

D. Lower isolation level to READ COMMITTED and add explicit locking where needed

Solution

1. Step 1: Understand SERIALIZABLE issues and evaluate best practice

   SERIALIZABLE prevents anomalies but causes serialization errors on conflicts. Lowering isolation risks anomalies; best is to keep SERIALIZABLE and retry failed transactions automatically.

2. Final Answer:

   Keep SERIALIZABLE and retry failed transactions automatically -> Option A

3. Quick Check:

   Retry on serialization errors = Keep SERIALIZABLE and retry failed transactions automatically [OK]

Hint: Retry failed SERIALIZABLE transactions to keep accuracy [OK]

Common Mistakes:

• Lowering isolation level without safeguards
• Ignoring serialization errors
• Disabling transactions for performance