Transaction Processing & ACID (OCR A-Level CS 1.3.2)
OCR A-Level CS 1.3.2: transaction processing and the ACID properties — atomicity, consistency, isolation and durability — plus record locking. Exam tips.

Free Transactions ACID revision resources (OCR A-Level Computer Science, 1.3.2)
We’ve made exam-style practice for this exact topic, free to download: Transactions ACID question sheet, mark scheme and cheat sheet. Grab them, have a go, then read the full guide below.
When you transfer money or book the last seat on a flight, the database must get it exactly right, even if two people act at once or the power fails mid-update. Spec point 1.3.2 covers transaction processing and the ACID properties, plus record locking — a steady source of Paper 1 marks, from "state what CID stands for" to "explain how record locking ensures isolation".
This guide explains what a transaction is, each ACID property, and how record locking works.

What is a transaction?
A transaction is a single logical operation on a database, often made of several steps that must all succeed or all fail together. A bank transfer is one transaction made of two steps: take money from account A and add it to account B. To be reliable, transactions follow the ACID properties.
What does ACID stand for?
Atomicity — a transaction is all or nothing. Either every step completes, or none does. If any step fails, the whole transaction is rolled back so the database is left as if it never started. (In the transfer, you never debit A without crediting B.)
Consistency — a transaction takes the database from one valid state to another, never breaking its rules (such as referential integrity or a balance that cannot go negative).
Isolation — concurrent transactions do not interfere with each other. Each runs as if it were the only one, so two transactions on the same data cannot produce a corrupted result.
Durability — once a transaction is committed, its changes are permanent, surviving a later crash or power loss. This is achieved by writing committed changes to non-volatile storage (often via a transaction log).
What is record locking?

Record locking is the technique that delivers isolation. When a transaction starts changing a record, the DBMS locks it so no other transaction can change it at the same time. The second transaction must wait until the first finishes (commits) and the lock is released.
This prevents the lost update problem, where two users read the same value, both change it, and one update overwrites the other. The trade-off is that locking can cause delays, and if two transactions each hold a lock the other needs, a deadlock can occur.
Worked example
Two customers try to book the last seat at the same time. Without isolation, both could read "1 seat free" and both book it. With record locking, the first transaction locks the seat record; the second waits; when the first commits ("0 seats free"), the second sees there are none left. Atomicity also matters: if payment fails after the seat is reserved, the whole booking is rolled back so the seat is freed.
Common exam mistakes
Confusing atomicity and consistency. Atomicity = all-or-nothing (rollback on failure); consistency = the database stays in a valid state.
Vague durability answers. Say committed changes are saved to non-volatile storage (e.g. a transaction log) so they survive a crash.
Forgetting which property locking serves. Record locking enforces isolation.
Ignoring locking's downsides. Mention possible delays and deadlock.
Treating a transaction as one step. It is often several steps that must all succeed together.
Quick recap
A transaction is one logical operation, often several steps that must all succeed or all fail.
ACID: Atomicity (all-or-nothing, rollback on failure), Consistency (stays in a valid state), Isolation (concurrent transactions don't interfere), Durability (committed changes are permanent, saved to non-volatile storage).
Record locking enforces isolation: a record being changed is locked until the transaction commits, preventing lost updates.
Locking can cause delays and, occasionally, deadlock.
Frequently asked questions
What is a transaction in a database? A transaction is a single logical operation on a database, often made up of several steps that must all succeed or all fail together, such as transferring money between two accounts. Transactions follow the ACID properties to stay reliable.
What does ACID stand for? ACID stands for Atomicity, Consistency, Isolation and Durability. These four properties ensure that database transactions are processed reliably, even when failures occur or several transactions run at the same time.
What does atomicity mean? Atomicity means a transaction is all-or-nothing: either every step is completed or none is. If any step fails, the whole transaction is rolled back so the database is left exactly as it was before the transaction started.
What does durability mean and how is it achieved? Durability means that once a transaction has been committed its changes are permanent and survive a later crash or power loss. It is achieved by writing the committed changes to non-volatile storage, often using a transaction log.
What is record locking? Record locking is a technique that enforces isolation. When a transaction is changing a record, the DBMS locks it so no other transaction can change it at the same time; other transactions must wait until the lock is released, preventing lost updates.
What is a disadvantage of record locking? Record locking can slow the system because transactions must wait for locks to be released. It can also cause a deadlock, where two transactions each hold a lock that the other needs, so neither can continue.


