Skip to content

Commit 2ee1967

Browse files
dinesh-2047dinesh-2047
committed
feat: Add SQL Transactions & Concurrency documentation
1 parent c2d8a89 commit 2ee1967

File tree

2 files changed

+253
-0
lines changed

2 files changed

+253
-0
lines changed

‎docs/sql/SQL-Advance/sql-transactions-concurrency.md‎

Lines changed: 252 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,252 @@
1+
---
2+
id: sql-transactions-concurrency
3+
title: SQL Transactions & Concurrency
4+
sidebar_label: Transactions & Concurrency
5+
sidebar_position: 13
6+
tags: [sql, transactions, concurrency, database, relational-databases]
7+
description: In this super beginner-friendly guide, you’ll learn about SQL transactions and concurrency—how to manage data changes safely and handle multiple users accessing the database at once!
8+
keywords: [sql, transactions, concurrency, ACID, isolation levels, locking, sql tutorial, sql basics, database management, sql for beginners, sql in 2025]
9+
---
10+
11+
12+
13+
## 📙 Welcome to SQL Transactions & Concurrency!
14+
15+
Hey there, SQL beginner! Transactions and concurrency are all about keeping your database safe and consistent when multiple operations or users are involved. Think of transactions as a way to group changes (like bank transfers) to ensure they’re done correctly, and concurrency as the rules for handling multiple users accessing the database at the same time. We’ll use a simple `students` table (with columns like `id`, `name`, `age`, `marks`, and `city`) to explain everything with clear examples. Let’s dive in step by step!
16+
17+
### 📘 What Are Transactions & Concurrency?
18+
19+
A **transaction** is a sequence of SQL operations (e.g., INSERT, UPDATE) treated as a single unit—either all succeed or none do. **Concurrency** deals with how databases manage multiple transactions happening simultaneously without causing issues like data corruption. Together, they ensure your database remains reliable.
20+
21+
We’ll cover:
22+
- **ACID Properties**: The rules that make transactions trustworthy.
23+
- **Transaction Commands**: COMMIT, ROLLBACK, SAVEPOINT for controlling transactions.
24+
- **Isolation Levels**: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE for managing concurrency.
25+
- **Locking**: Row-level vs. table-level locks to prevent conflicts.
26+
27+
> **Pro Tip**: Understanding transactions and concurrency helps you avoid errors like lost updates or inconsistent data in multi-user environments!
28+
29+
### 📘 ACID Properties (The Rules of Safe Transactions!)
30+
31+
ACID stands for **Atomicity**, **Consistency**, **Isolation**, and **Durability**—the four properties that ensure transactions are reliable.
32+
33+
**The Four Properties**:
34+
- **Atomicity**: Ensures all operations in a transaction complete successfully, or none are applied (all-or-nothing).
35+
- **Consistency**: Guarantees the database remains in a valid state before and after a transaction (e.g., no broken rules like foreign key violations).
36+
- **Isolation**: Ensures transactions are independent, so partial changes from one transaction aren’t visible to others until complete.
37+
- **Durability**: Guarantees that once a transaction is committed, changes are permanently saved, even if the system crashes.
38+
39+
**Example**:
40+
:::info
41+
<Tabs>
42+
<TabItem value="SQL Code" label="SQL Code">
43+
```sql title="Demonstrating ACID in a Transaction"
44+
START TRANSACTION;
45+
UPDATE students SET marks = marks + 10 WHERE id = 1; -- Atomicity: Part of a single unit
46+
INSERT INTO students (id, name, age, marks, city) VALUES (4, 'Dave', 18, 80, 'Mumbai');
47+
-- Consistency: Ensures marks are valid, no duplicates in id
48+
COMMIT; -- Durability: Changes saved permanently
49+
-- Isolation: Other users don’t see changes until COMMIT
50+
```
51+
</TabItem>
52+
53+
<TabItem value="Output" label="Output">
54+
1 row updated, 1 row inserted in `students`. Transaction committed.
55+
</TabItem>
56+
</Tabs>
57+
:::
58+
59+
> **What NOT to Do**: Don’t assume all databases enforce ACID fully—some (e.g., older NoSQL systems) may sacrifice consistency for performance. Check your DBMS documentation!
60+
61+
### 🔄 Transaction Commands (Controlling Your Changes!)
62+
63+
These commands manage transactions to ensure data integrity. They belong to TCL (Transaction Control Language).
64+
65+
**Three Key Commands**:
66+
- **COMMIT**: Saves all changes in a transaction permanently.
67+
- **ROLLBACK**: Undoes all changes since the transaction started.
68+
- **SAVEPOINT**: Sets a checkpoint to partially roll back to.
69+
70+
**Examples**:
71+
:::info
72+
<Tabs>
73+
<TabItem value="COMMIT" label="COMMIT">
74+
```sql title="Using COMMIT"
75+
START TRANSACTION;
76+
INSERT INTO students (id, name, age, marks, city) VALUES (3, 'Carol', 19, 75, 'Delhi');
77+
COMMIT; -- Saves the INSERT
78+
```
79+
</TabItem>
80+
81+
<TabItem value="COMMIT Output" label="COMMIT Output">
82+
1 row inserted. Transaction committed.
83+
</TabItem>
84+
85+
<TabItem value="ROLLBACK" label="ROLLBACK">
86+
```sql title="Using ROLLBACK"
87+
START TRANSACTION;
88+
UPDATE students SET marks = 100 WHERE id = 3;
89+
ROLLBACK; -- Undoes the UPDATE
90+
```
91+
</TabItem>
92+
93+
<TabItem value="ROLLBACK Output" label="ROLLBACK Output">
94+
Transaction rolled back; no changes saved.
95+
</TabItem>
96+
97+
<TabItem value="SAVEPOINT" label="SAVEPOINT">
98+
```sql title="Using SAVEPOINT"
99+
START TRANSACTION;
100+
INSERT INTO students (id, name, age, marks, city) VALUES (5, 'Eve', 21, 88, 'Delhi');
101+
SAVEPOINT save1;
102+
UPDATE students SET marks = 90 WHERE id = 5;
103+
ROLLBACK TO save1; -- Keeps INSERT, undoes UPDATE
104+
COMMIT;
105+
```
106+
</TabItem>
107+
108+
<TabItem value="SAVEPOINT Output" label="SAVEPOINT Output">
109+
1 row inserted. Rolled back to save1; UPDATE undone. Transaction committed.
110+
</TabItem>
111+
</Tabs>
112+
:::
113+
114+
> **What NOT to Do**:
115+
> - Don’t forget to COMMIT or ROLLBACK—uncommitted transactions can lock resources!
116+
> - Don’t overuse SAVEPOINTs; they can make transaction logic hard to follow.
117+
118+
### 📘 Isolation Levels (Managing Concurrent Transactions!)
119+
120+
Isolation levels define how much one transaction’s changes are visible to others, balancing consistency with performance. They control concurrency issues like **dirty reads** (reading uncommitted data), **non-repeatable reads** (data changing during a transaction), and **phantom reads** (new rows appearing).
121+
122+
**Four Standard Levels** (from least to most strict):
123+
- **READ UNCOMMITTED**: Allows reading uncommitted changes (risk of dirty reads).
124+
- **READ COMMITTED**: Only reads committed data, but allows non-repeatable reads.
125+
- **REPEATABLE READ**: Ensures consistent reads within a transaction, but phantom reads are possible.
126+
- **SERIALIZABLE**: Strictest; transactions run as if one at a time, preventing all concurrency issues.
127+
128+
**Examples**:
129+
:::info
130+
<Tabs>
131+
<TabItem value="READ UNCOMMITTED" label="READ UNCOMMITTED">
132+
```sql title="Setting READ UNCOMMITTED"
133+
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
134+
START TRANSACTION;
135+
SELECT marks FROM students WHERE id = 1; -- May see uncommitted changes
136+
COMMIT;
137+
```
138+
</TabItem>
139+
140+
<TabItem value="READ UNCOMMITTED Output" label="Output">
141+
| marks |
142+
|-------|
143+
| 85 | -- Could include uncommitted data
144+
Transaction committed.
145+
</TabItem>
146+
147+
<TabItem value="READ COMMITTED" label="READ COMMITTED">
148+
```sql title="Setting READ COMMITTED"
149+
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
150+
START TRANSACTION;
151+
SELECT marks FROM students WHERE id = 1; -- Only committed data
152+
COMMIT;
153+
```
154+
</TabItem>
155+
156+
<TabItem value="READ COMMITTED Output" label="Output">
157+
| marks |
158+
|-------|
159+
| 85 |
160+
Transaction committed.
161+
</TabItem>
162+
163+
<TabItem value="REPEATABLE READ" label="REPEATABLE READ">
164+
```sql title="Setting REPEATABLE READ"
165+
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
166+
START TRANSACTION;
167+
SELECT marks FROM students WHERE id = 1; -- Consistent during transaction
168+
-- Another SELECT here returns same marks
169+
COMMIT;
170+
```
171+
</TabItem>
172+
173+
<TabItem value="REPEATABLE READ Output" label="Output">
174+
| marks |
175+
|-------|
176+
| 85 |
177+
Transaction committed.
178+
</TabItem>
179+
180+
<TabItem value="SERIALIZABLE" label="SERIALIZABLE">
181+
```sql title="Setting SERIALIZABLE"
182+
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
183+
START TRANSACTION;
184+
SELECT * FROM students WHERE city = 'Mumbai'; -- No phantom rows
185+
COMMIT;
186+
```
187+
</TabItem>
188+
189+
<TabItem value="SERIALIZABLE Output" label="Output">
190+
| id | name | age | marks | city |
191+
|----|-------|-----|-------|--------|
192+
| 1 | Alice | 20 | 85 | Mumbai |
193+
Transaction committed.
194+
</TabItem>
195+
</Tabs>
196+
:::
197+
198+
> **What NOT to Do**:
199+
> - Don’t use READ UNCOMMITTED unless you’re okay with potentially inconsistent data!
200+
> - Don’t default to SERIALIZABLE for all queries—it can slow down performance due to heavy locking.
201+
202+
### 🔄 Locking: Row-Level vs. Table-Level Locks (Preventing Conflicts!)
203+
204+
Locking prevents conflicts when multiple transactions access the same data. Locks can be **row-level** (affecting specific rows) or **table-level** (affecting the entire table).
205+
206+
**Row-Level vs. Table-Level**:
207+
- **Row-Level Locks**: Only lock specific rows involved in a transaction, allowing other rows to be accessed. Common in UPDATE or SELECT ... FOR UPDATE.
208+
- **Table-Level Locks**: Lock the entire table, restricting access to all rows. Used in DDL operations or explicit LOCK TABLE commands.
209+
210+
**Examples**:
211+
:::info
212+
<Tabs>
213+
<TabItem value="Row-Level Lock" label="Row-Level Lock">
214+
```sql title="Using Row-Level Lock"
215+
START TRANSACTION;
216+
SELECT * FROM students WHERE id = 1 FOR UPDATE; -- Locks only row with id=1
217+
UPDATE students SET marks = 95 WHERE id = 1;
218+
COMMIT;
219+
```
220+
</TabItem>
221+
222+
<TabItem value="Row-Level Lock Output" label="Output">
223+
Row with id=1 locked and updated. Transaction committed.
224+
</TabItem>
225+
226+
<TabItem value="Table-Level Lock" label="Table-Level Lock">
227+
```sql title="Using Table-Level Lock"
228+
LOCK TABLES students WRITE; -- Locks entire table
229+
UPDATE students SET marks = marks + 5;
230+
UNLOCK TABLES;
231+
```
232+
</TabItem>
233+
234+
<TabItem value="Table-Level Lock Output" label="Output">
235+
Table `students` locked, all rows updated, table unlocked.
236+
</TabItem>
237+
</Tabs>
238+
:::
239+
240+
> **What NOT to Do**:
241+
> - Don’t use table-level locks for small updates—row-level locks are more efficient!
242+
> - Don’t hold locks longer than necessary; it can cause deadlocks or slow down other users.
243+
244+
## ✅ What You’ve Learned
245+
246+
You’re now a pro at SQL transactions and concurrency! You’ve mastered:
247+
- **ACID Properties**: Atomicity, Consistency, Isolation, Durability for reliable transactions.
248+
- **Transaction Commands**: COMMIT, ROLLBACK, SAVEPOINT for controlling changes.
249+
- **Isolation Levels**: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE for managing concurrency.
250+
- **Locking**: Row-level vs. table-level locks to prevent conflicts.
251+
252+
Practice these concepts with the `students` table in a multi-user environment. Follow the “What NOT to Do” tips to keep your database safe and performant!

‎sidebars.ts‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -168,6 +168,7 @@ const sidebars: SidebarsConfig = {
168168
"sql/SQL-Advance/sql-advanced-analytics",
169169
"sql/SQL-Advance/sql-procedures-functions-triggers",
170170
"sql/SQL-Advance/dimensional-modelling",
171+
"sql/SQL-Advance/sql-transactions-concurrency",
171172
],
172173
},
173174
],

0 commit comments

Comments
 (0)