🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🔒 धडा 07 — Concurrency आणि isolation: दोन कारकून, एक नोंदवही

📍 तुम्ही इथे आहात: 18 पैकी धडा 07 — भाग 2 सुरू! · मागे: lesson-06-indexes · पुढे: lesson-08-migrations

📦 या ब्रँचमध्ये काय आहे

धडे 01–06, आणि दोन clerks ना एकाच वेळी तीच नोंदवही हवी असते तेव्हा काय होते: locks, isolation levels, आणि deadlock चे हस्तांदोलन.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

Clerk 2 students नोंदवही उघडते, pencil ने "Katrina → Katrina K" लिहिते (BEGIN, UPDATE) आणि शाईने पक्के करण्याआधी काहीतरी तपासायला निघून जाते. Clerk 1 येते:

Clerk 1 कतरिनाची ओळ वाचते. तिला जुने नाव दिसते. शाईने पक्क्या होईपर्यंत pencil खुणा खाजगी असतात — हेच isolation. अर्धवट कामात डोकावणे नाही.
Clerk 1 ला सुद्धा कतरिनाची ओळ लिहायची आहे. नोंदवही clerk 2 च्या pencil ने धरून ठेवली आहे. Clerk 1 lock साठी थांबते… आणि काही वेळाने हार मानते: "database is locked". lock ने त्या ओळीला एकाच वेळी दोन pencils पासून वाचवले.

वाचणारीला किती pencil दिसू शकते? ते बटण म्हणजे isolation level: "फक्त शाईने लिहिलेल्या ओळी" (read committed, नेहमीचा default) पासून "जणू एका वेळी एकच clerk काम करत आहे" (serializable) पर्यंत. जास्त कडक म्हणजे जास्त सुरक्षित आणि जास्त थांबणे.

आणि क्लासिक सापळा — deadlock: clerk 1 ने students नोंदवही धरली आहे आणि तिला grades हवी आहे; clerk 2 ने grades धरली आहे आणि तिला students हवी आहे. कोणीच हलू शकत नाही. दप्तरदार एकीला निवडतो, तिचे pencil काम फाडून टाकतो, आणि तिला पुन्हा सुरुवात करायला सांगतो. उपाय कंटाळवाणा आहे: transactions लहान ठेवा, आणि प्रत्येक वेळी नोंदवह्या एकाच क्रमाने घ्या.

🗺️ आकृती

sequenceDiagram
    participant A as 🧑‍💼 clerk 1
    participant DB as 🗄️ register
    participant B as 🧑‍💼 clerk 2
    B->>DB: 1 BEGIN; UPDATE students SET name='Katrina K' WHERE id=2 (pencil, not committed)
    A->>DB: 2 SELECT name WHERE id=2
    DB-->>A: 'Katrina' — the old, inked value (isolation)
    A->>DB: 3 UPDATE students SET name='Katrina R' WHERE id=2
    DB-->>A: ⏳ waits for the lock… 'database is locked'
    B->>DB: 4 ROLLBACK (pencil erased) — the register is free again

❓ काय

Locks: लिहिणारे जे बदलतात त्यावर lock घेतात; इतर लिहिणारे थांबतात. SQLite writes साठी संपूर्ण database file lock करते (एका वेळी एकच writer, WAL mode मध्ये अनेक readers); Postgres आणि MySQL rows lock करतात, म्हणून वेगवेगळ्या विद्यार्थिनींवर काम करणाऱ्या दोन clerks एकमेकींची वाट पाहत नाहीत.
Isolation levels (SQL standard): read uncommitted (pencil दिसते — जवळजवळ कधीच वापरत नाहीत), read committed (Postgres default), repeatable read (MySQL default; एका transaction मध्ये तेच read त्याच rows परत देते), serializable (जणू क्रमाने; "मला retry करा" म्हणून abort होऊ शकते).
सैल levels परवानगी देतात त्या anomalies: dirty read, non-repeatable read, phantom rows, lost update (दोन clerks 5 वाचतात, दोघी 6 लिहितात). counters आणि पैशांसाठी: SELECT … FOR UPDATE, किंवा serializable, किंवा atomic UPDATE … SET n = n + 1.
Deadlock: वाट पाहण्याचे वर्तुळ. database ते ओळखतो आणि एक transaction abort करतो; तुमचा code retry करायला तयार हवा.
Timeouts: प्रत्येक lock wait ला एक हवा (आमच्या connection मध्ये timeout=1.0) — timeout शिवायची प्रतीक्षा म्हणजे hang.

🤔 का

कारण "सामायिक" (धडा 01 चे दुसरे वचन) हे तिन्हींपैकी सर्वात कठीण आहे. इथले bugs tests मध्ये अदृश्य (एक user) आणि production मध्ये विनाशकारी असतात (sale, ticket drop, payroll run): दोनदा book झालेल्या जागा आणि हरवलेले updates म्हणजे business चा वेश घातलेल्या isolation समस्या.

🔧 कसे (या repo मध्ये)

db/demo.py मधील locks() दुसरे connection उघडते, commit न केलेल्या UPDATE सह BEGIN IMMEDIATE (write lock) सुरू करते, मग clerk 1 जुनी value वाचताना आणि timeout मध्ये लिहिण्यात अपयशी होताना दाखवते.

🧪 करून पाहा

python3 db/demo.py locks
python3 - <<'EOF'
import sqlite3, threading
def clerk(name, delta):
    c = sqlite3.connect("db/school.db", timeout=5)
    with c:                                                       # atomic increment: no lost update
        c.execute("UPDATE homework SET title = title || ?", (delta,))
    print(name, "done")
ts = [threading.Thread(target=clerk, args=(f"clerk {i}", "!")) for i in range(5)]
[t.start() for t in ts]; [t.join() for t in ts]
c = sqlite3.connect("db/school.db"); print(c.execute("SELECT title FROM homework").fetchall())
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

locks clerk 1 च्या read साठी जुने नाव छापतो आणि मग timeout नंतर database is locked. तुमचे पाच threads प्रत्येकी एक ! जोडतात — प्रत्येक title अगदी पाच ! ने संपते: lock ने writers ना एकामागून एक लावले आणि एकही update हरवला नाही.

🏁 तुम्ही आत्ताच काय सिद्ध केले

Readers ना कधीच pencil दिसत नाही, writers lock साठी थांबतात, आणि पाच एकाचवेळचे updates पाच म्हणूनच उतरले — एकाने इतरांवर overwrite करून नव्हे.

⚠️ नेहमीच्या चुका

दोन statements मध्ये read-then-write (SELECT n … UPDATE SET n = 6) — lost update; SET n = n + 1 किंवा row lock वापरा
user ची वाट पाहत उघडी राहणारी transactions — बाकी सगळे सुद्धा थांबतात
deadlocks/serialization failures साठी retry logic नसणे — database कधी ना कधी तुम्हाला abort करणारच
तुमच्या ORM चा default isolation serializable आहे असे गृहीत धरणे — तो जवळजवळ नेहमी read committed असतो
timeout शिवायचे lock waits

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: "flash sale मध्ये 100 पैकी 101 items विकले" ही गोष्ट म्हणजे lost update; "रात्री 9 ला checkout अडकतो" ही गोष्ट म्हणजे lock धरून बसलेले लांब transaction. इथे एकदा अनुभवल्यावर दोन्हींचे निदान धडा 07 च्या एका वाक्यात होते.

⏭️ पुढे

शाळा चालू असतानाच नोंदवह्या बदलाव्या लागतात: migrations — versioned scripts, logbook, आणि expand → migrate → contract.

git checkout lesson-08-migrations

🔒 Lesson 07 — Concurrency & isolation: two clerks, one register

📍 You are here: Lesson 07 of 18 — Part 2 begins! · Previous: lesson-06-indexes · Next: lesson-08-migrations

📦 What's in this branch

Lessons 01–06, plus what happens when two clerks want the same register at the same time: locks, isolation levels, and the deadlock handshake.

🧒 Explain like I'm 5

Clerk 2 opens the students register, writes in pencil "Katrina → Katrina K" (BEGIN, UPDATE) and walks off to check something before inking it. Clerk 1 arrives:

Clerk 1 reads Katrina's line. She sees the old name. Pencil marks are private until inked — that is isolation. No peeking at half-done work.
Clerk 1 wants to write Katrina's line too. The register is held by clerk 2's pencil. Clerk 1 waits for the lock… and after a while gives up: "database is locked". The lock protected the line from two pencils at once.

How much pencil may a reader see? That dial is the isolation level: from "only inked lines" (read committed, the usual default) to "as if one clerk worked at a time" (serializable). Stricter means safer and means more waiting.

And the classic trap — the deadlock: clerk 1 holds the students register and wants grades; clerk 2 holds grades and wants students. Neither can move. The archivist picks one, tears up their pencil work, and tells them to start over. The cure is boring: keep transactions short, and take registers in the same order every time.

🗺️ Diagram

sequenceDiagram
    participant A as 🧑‍💼 clerk 1
    participant DB as 🗄️ register
    participant B as 🧑‍💼 clerk 2
    B->>DB: 1 BEGIN; UPDATE students SET name='Katrina K' WHERE id=2 (pencil, not committed)
    A->>DB: 2 SELECT name WHERE id=2
    DB-->>A: 'Katrina' — the old, inked value (isolation)
    A->>DB: 3 UPDATE students SET name='Katrina R' WHERE id=2
    DB-->>A: ⏳ waits for the lock… 'database is locked'
    B->>DB: 4 ROLLBACK (pencil erased) — the register is free again

❓ What

Locks: writers take a lock on what they change; other writers wait. SQLite locks the whole database file for writes (one writer at a time, many readers with WAL mode); Postgres and MySQL lock rows, so two clerks on different students do not wait for each other.
Isolation levels (SQL standard): read uncommitted (see pencil — almost never used), read committed (Postgres default), repeatable read (MySQL default; the same read returns the same rows within a transaction), serializable (as if sequential; may abort with "retry me").
Anomalies the looser levels allow: dirty read, non-repeatable read, phantom rows, lost update (two clerks read 5, both write 6). For counters and money: SELECT … FOR UPDATE, or serializable, or an atomic UPDATE … SET n = n + 1.
Deadlock: a cycle of waits. The database detects it and aborts one transaction; your code must be ready to retry.
Timeouts: every lock wait needs one (timeout=1.0 in our connection) — a wait without a timeout is a hang.

🤔 Why

Because "shared" (lesson 01's second promise) is the hardest of the three. The bugs here are invisible in tests (one user) and catastrophic in production (a sale, a ticket drop, a payroll run): double-booked seats and lost updates are isolation problems wearing a business costume.

🔧 How (in this repo)

locks() in db/demo.py opens a second connection, starts BEGIN IMMEDIATE (the write lock) with an uncommitted UPDATE, then shows clerk 1 reading the old value and failing to write within the timeout.

🧪 Try it

python3 db/demo.py locks
python3 - <<'EOF'
import sqlite3, threading
def clerk(name, delta):
    c = sqlite3.connect("db/school.db", timeout=5)
    with c:                                                       # atomic increment: no lost update
        c.execute("UPDATE homework SET title = title || ?", (delta,))
    print(name, "done")
ts = [threading.Thread(target=clerk, args=(f"clerk {i}", "!")) for i in range(5)]
[t.start() for t in ts]; [t.join() for t in ts]
c = sqlite3.connect("db/school.db"); print(c.execute("SELECT title FROM homework").fetchall())
EOF

✅ Verify — what you should see

locks prints the old name for clerk 1's read and then database is locked after the timeout. Your five threads each append one ! — every title ends with exactly five !: the lock serialised the writers and no update was lost.

🏁 What you just proved

Readers never see pencil, writers wait for the lock, and five concurrent updates landed as five — not as one overwriting the others.

⚠️ Common mistakes

read-then-write in two statements (SELECT n … UPDATE SET n = 6) — the lost update; use SET n = n + 1 or a row lock
transactions that stay open while waiting for a user — everyone else waits too
no retry logic for deadlocks/serialization failures — the database will abort you sometimes
assuming your ORM's default isolation is serializable — it is almost always read committed
lock waits with no timeout

🏭 Why this matters in production: the "flash sale sold 101 of 100 items" story is a lost update; the "checkout hangs at 9 pm" story is a long transaction holding a lock. Both are a lesson-07 sentence to diagnose once you have felt them here.

⏭️ Next

The registers must change while school is open: migrations — versioned scripts, the logbook, and expand → migrate → contract.

git checkout lesson-08-migrations

← Previousindexes Next →migrations

This page is the lesson's README from the lesson-07-concurrency branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.