Revision notes for AQA A Level Computer Science Client server databases. Open the guide for explanations and worked examples. Written against the AQA A Level Computer Science specification, so the content matches what's examinable rather than general Computer Science background.
Client server databases
What you'll learn
- What a client-server database system is and why it supports many users at once.
- Why concurrent access can cause a lost update.
- How record locks, serialisation, timestamp ordering and commitment ordering protect database integrity.
- How to explain these ideas clearly in A-Level exam answers.
The basic setup: clients, server and DBMS
A client is a program or device that requests a service. In this topic, the client might be a till system, a web browser, a school management app, or a banking app.
A server is a computer or process that provides a service to clients. A database server stores and manages a shared database.
A DBMS stands for database management system. It is the software that controls the database: it processes queries, enforces rules, controls access, and writes changes to storage.
Definition
Client-server database system
A client-server database system stores the database centrally on a server, while multiple clients send requests to the server to read or change data.
In a client-server database, users do not usually edit the database file directly. Instead, clients send requests such as SELECT, INSERT, UPDATE and DELETE to the DBMS. The DBMS decides how and when those operations are carried out.
Key Idea
Shared database, central control
Many clients can use the same database at the same time, but the DBMS must control conflicting operations so that the stored data remains correct.
Simultaneous access
A client-server database system provides simultaneous access to the database for multiple clients. This means several users can appear to use the database at the same time.
For example:
- two customers buy the same product online
- two teachers update the same student record
- two bank cashiers access the same account
- several booking agents try to reserve the last seat on a flight
This is useful because real systems have many users. However, it creates a problem: what if two clients try to change the same record at nearly the same time?
Definition
Concurrent access
Concurrent access means that operations from two or more clients overlap in time. The DBMS may interleave their reads and writes rather than completing one whole user action before starting the next.
Records, transactions and integrity
A record is one stored row or item in a database table. For example, in a Customer table, one customer’s details would usually be one record.
An update is a change to stored data. Updating a record often follows a read-modify-write pattern:
- read the current value
- calculate or decide the new value
- write the new value back to the database
A transaction is a sequence of database operations treated as one logical unit. A transaction normally ends by being either:
- committed: its changes are made permanent
- rolled back: its changes are undone
Definition
Database integrity
Database integrity means the data remains accurate, consistent and valid after operations have been carried out.
For this topic, the key threat to integrity is not that the database cannot store data. The threat is that overlapping updates may interfere with each other.
The lost update problem
A lost update happens when two clients update the same record, but one client’s change is overwritten by the other client’s change.
This often happens when both clients read the old value before either of them writes a new value.
Example
Spotting a lost update
A product record starts with StockLevel = 10. Client A sells 3 items. Client B receives 5 new items into stock.
| Time | Client A | Client B | Stored stock |
|---|---|---|---|
| 1 | Reads 10 | 10 | |
| 2 | Reads 10 | 10 | |
| 3 | Calculates new value 7 | 10 | |
| 4 | Calculates new value 15 | 10 | |
| 5 | Writes 15 | 15 | |
| 6 | Writes 7 | 7 |
- The correct final result should include both changes: stock decreases by 3 and increases by 5, so (10−3)+5=12(10 - 3) + 5 = 12(10−3)+5=12.
- Both clients read the old value 10 before either write is made, so each calculation is based on a stale copy of the record.
- The final stored value is 7 because Client A writes last. Client B’s increase has been overwritten, so Client B’s update has been lost.
Common Mistake
Last write wins is not integrity
Do not describe “the most recent client’s value is stored” as a solution. That is exactly how a lost update can occur: the final write overwrites another valid change.
Concurrency control
Concurrency control is how the DBMS manages overlapping transactions so that data remains consistent.
The aim is not always to stop simultaneous access completely. That would make the system slow and wasteful. Instead, the DBMS should allow safe operations to happen at the same time, while controlling operations that conflict.
Definition
Concurrency control
Concurrency control is the set of techniques used by a DBMS to manage simultaneous access to shared data while preserving database integrity.
The AQA specification names four ways concurrent access can be controlled:
- record locks
- serialisation
- timestamp ordering
- commitment ordering
Record locks
A lock is a control placed on data so that other transactions cannot perform conflicting operations on it.
A record lock applies to one record. If a client is changing a particular record, the DBMS can lock that record so another client cannot change it at the same time.
A typical update using a record lock is:
- transaction requests a lock on the record
- DBMS grants the lock if it is available
- transaction reads and updates the record
- transaction commits
- DBMS releases the lock
If another client tries to update the same locked record, it must wait or be restarted. Other clients may still be able to access different records.
Example
Preventing the lost update with a record lock
Use the same stock example: the product starts with StockLevel = 10. Client A sells 3 items and Client B receives 5 items.
- Client A requests a lock on the product record. Since no other transaction holds the lock, the DBMS grants it. Client B’s conflicting request for the same record must wait.
- Client A reads 10, applies the sale, writes 7, then executes
COMMIT. The DBMS releases the record lock. - Client B can now lock the record and reads the current value 7, not the old value 10. It applies the delivery: 7+5=127 + 5 = 127+5=12, writes 12, and commits.
- Both changes have been included, so no update has been lost.
Common Mistake
Locks can reduce concurrency
Locks protect integrity, but a transaction that keeps a lock for a long time can make other clients wait. A DBMS has to balance safety with performance.
Serialisation
A serial schedule runs transactions one after another, with no overlap. For example, Transaction A completes fully, then Transaction B starts.
Serialisation means ensuring that the effect of concurrent transactions is the same as some safe serial order.
Definition
Serialisation
Serialisation controls transactions so the final result is equivalent to running those transactions one at a time in a valid order.
This does not always mean the DBMS literally runs only one transaction at once. It may interleave operations where safe. The important point is that the final database state must be the same as if the transactions had happened one after another.
For the stock example, both valid serial orders give the same final stock:
- Client A then Client B: sell 3, then receive 5
- Client B then Client A: receive 5, then sell 3
Both include both updates. The lost update schedule is not acceptable because it is not equivalent to either safe serial order.
Key Idea
Think as if one-at-a-time
When explaining serialisation, say that concurrent transactions are controlled so the final result is as though they were processed one at a time.
Timestamp ordering
A timestamp is a value assigned to a transaction, often based on when it starts. It gives transactions an order.
Timestamp ordering uses these timestamps to decide the order in which conflicting transactions should behave. If two transactions conflict, the DBMS uses their timestamps to preserve a consistent order.
For example, if Transaction A starts before Transaction B, the DBMS may enforce the rule that A must be treated as earlier than B for conflicting operations. If B has already done something that would break that order, B may be delayed, rolled back, or restarted.
Definition
Timestamp ordering
Timestamp ordering controls concurrent transactions by assigning timestamps and ensuring conflicting operations are processed in timestamp order.
Example
Ordering two conflicting transactions
Client A and Client B both update the same product record. Client A starts first, then Client B starts later.
- The DBMS assigns Client A the earlier timestamp and Client B the later timestamp, so the required order for conflicting operations is A before B.
- If Client B’s update request reaches the server first, the DBMS must not allow it to permanently break the timestamp order. It can delay, reject, roll back, or restart a transaction depending on the DBMS design.
- Once Client A’s update has been safely applied, Client B’s transaction can be processed using the state left by Client A.
- The final result is equivalent to the serial order A then B, so the lost update is avoided.
Commitment ordering
A commit makes a transaction’s changes permanent. Commitment ordering controls the order in which transactions are allowed to commit.
The key idea is that the commit order must respect the dependencies between conflicting transactions. If one transaction’s result depends on another transaction, the dependent transaction should not commit first.
Definition
Commitment ordering
Commitment ordering preserves integrity by ensuring that the order in which transactions commit is consistent with the safe order of their conflicting operations.
This helps avoid situations where a transaction is made permanent even though it relied on another transaction that has not safely completed.
For A-Level, you do not need to know a full industrial database algorithm for this. You should be able to explain that the DBMS controls the commit order of transactions so that conflicts cannot leave the database in an inconsistent state.
Comparing the techniques
| Technique | Core idea | How it prevents lost updates |
|---|---|---|
| Record locks | Temporarily lock the record being changed | Another client cannot overwrite the same record until the lock is released |
| Serialisation | Make the result equivalent to one-at-a-time processing | Conflicting updates are ordered safely |
| Timestamp ordering | Give transactions timestamps and enforce that order | Later transactions cannot invalidate earlier conflicting transactions |
| Commitment ordering | Control the order in which transactions commit | Dependent or conflicting transactions are made permanent in a safe order |
Common Mistake
Backups are not concurrency control
A backup may help recover data after a failure, but it does not stop two clients overwriting each other during normal operation. For this topic, focus on how the DBMS controls simultaneous access.
What to say about preserving integrity
A strong explanation links the problem and the solution:
- Multiple clients can access a shared database at the same time.
- Their operations may overlap.
- If two clients update the same record, one update may overwrite the other.
- The DBMS uses concurrency control to force a safe order.
- Techniques include record locks, serialisation, timestamp ordering and commitment ordering.
Tip
A good exam phrase
“Concurrent transactions are controlled so that conflicting updates are processed in a safe order, preserving database integrity and preventing lost updates.”
Exam technique
In the exam
- If asked what a client-server database provides, mention simultaneous access for multiple clients to a centrally managed database.
- If asked about the danger of concurrent access, describe a lost update: two clients read the same old value, both calculate changes, and one write overwrites the other.
- If asked how integrity is preserved, name and explain relevant controls: record locks, serialisation, timestamp ordering and commitment ordering.
Self review
Check yourself
- Why can two clients updating the same record at the same time cause a lost update?
- How does a record lock stop one client overwriting another client’s change?
- What is the difference between timestamp ordering and commitment ordering?
You've reached the end
Test yourself on this topic, or move on to the next guide.
How was this guide?