A database looks calm from the outside. You run a query, it answers. You update a record, it nods politely.
Then exam season hits, you try to revise IB Computer Science, and you realise databases have a secret life: dozens (sometimes thousands) of users doing things at nearly the same time. That overlapping timing is where concurrency problems are born. Not because databases are “bad,” but because reality is messy.
Two concurrency problems show up again and again in IB Computer Science exam questions: lost updates and dirty reads. If you can explain them with a clean timeline and link them to isolation (ACID), you usually pick up easy marks.
Quick checklist: what the examiner wants
Keep this mini checklist in mind when answering IB Computer Science database concurrency questions:
-
Define concurrency (overlapping transactions on the same data)
-
Name the problem (lost update vs dirty read)
-
Explain when it happens (sequence/timing)
-
State the consequence (incorrect final value or unreliable read)
-
Link to ACID, especially Isolation
-
Mention prevention ideas (locking, isolation levels, control mechanisms)
If you want a bigger picture refresher on transactions first, pair this with Transactions Explained: ACID.
Concurrency in IB Computer Science (the simple meaning)
In IB Computer Science, concurrency means more than “many users exist.” It means multiple transactions overlap in time and touch the same shared data.
Think of a school system where students are enrolling at once, or a ticketing site during a concert drop. Concurrency helps performance and responsiveness, but it also creates risk: two transactions can collide.
If you need a syllabus-aligned definition and framing, RevisionDojo’s notes on concurrent solution implementation are a fast way to anchor the vocabulary.
Lost updates: when one change quietly erases another
A lost update happens when:
-
Transaction A reads a value
-
Transaction B reads the same value (before A finishes)
-
Both compute a new value
-
The later write overwrites the earlier write
So one update “wins,” and the other is effectively deleted from history.
Lost update example you can write in an exam
Imagine a balance is 100.
-
A reads 100, plans to add 20 (new balance 120)
-
B reads 100, plans to subtract 30 (new balance 70)
-
A writes 120
-
B writes 70
Final balance becomes 70, but the correct outcome (if both happened safely) would be 90.
That gap is the lost update: A’s +20 existed, then vanished.
Why lost updates matter in IB Computer Science
Lost updates are a classic sign of poor isolation. In IB Computer Science, you’re often expected to say something like: “The transactions were not isolated, so they interfered, causing an incorrect final state.”
Real systems where this is dangerous include inventory counts, grade records, and banking. Anywhere two legitimate actions should both be applied, overwriting becomes a silent data integrity failure.
To strengthen your transaction-language, see A.1.2 Transactions and Data Consistency and the matching notes.
Dirty reads: trusting a change that never “really” happened
A dirty read happens when:
-
Transaction A updates data but has not committed yet
-
Transaction B reads that updated value anyway
-
Transaction A later rolls back
Now B has used information that was never actually valid in the committed database.
Dirty read example you can explain step-by-step
-
A changes “Seats remaining” from 1 to 0 (but hasn’t committed)
-
B reads 0 and tells a user “Sold out”
-
A fails and rolls back to 1
B’s decision was based on a temporary, uncommitted state. In IB Computer Science, that’s the key phrase: uncommitted data becomes visible.
Why dirty reads break consistency
Dirty reads don’t just produce a wrong number. They produce a wrong story. Another transaction acts on information that might be undone. That’s why they’re tied tightly to the Isolation part of ACID, and why databases use controls so intermediate states stay hidden.
If you want broader database context for IB Computer Science, these quick reads help:
How databases prevent lost updates and dirty reads
For IB Computer Science, you don’t need to memorise every isolation level detail, but you should name the big ideas:
-
Transaction isolation: keep transactions from interfering
-
Locking: prevent other transactions from reading/writing certain data until safe
-
Controlled commit/rollback behavior: changes become visible at the right time
This connects directly to ACID. Atomicity ensures “all or nothing,” while Isolation helps ensure “no interference.” If you want to practise applying this in exam-style prompts, RevisionDojo’s Databases questionbank is built for that.
RevisionDojo also makes the workflow practical: use Study Notes to learn the definitions, Flashcards to lock in the terms, then hit the Questionbank for exam phrasing. If you’re unsure why your explanation drops marks, the AI Chat and Grading tools help you tighten wording fast.
Common IB exam mistakes (and how to avoid them)
-
Mixing up the consequences: lost update = overwritten write; dirty read = reading uncommitted data
-
Forgetting the timeline: concurrency problems are mostly about order of events
-
Not linking to ACID: in IB Computer Science, “Isolation” is often the intended keyword
To reinforce concurrency language quickly, use RevisionDojo’s Computer Science hub and the concurrency flashcards inside the course.
Closing: make concurrency your easy-mark topic
Concurrency problems feel abstract until you see what they really are: two honest actions colliding because time overlaps. In IB Computer Science, your job is to narrate that collision clearly. Lost updates erase changes. Dirty reads trust changes that never commit.
If you want to turn this into reliable exam marks, build a short routine on RevisionDojo: read the Study Notes, drill the Flashcards, attempt database questions in the Questionbank, then use AI Chat to polish your explanation style. Add a Mock Exam when you’re ready, and if you want extra guidance, RevisionDojo Tutors can help you correct the small phrasing mistakes that cost big marks in IB Computer Science.