Study resource
Client server databases revision notes
Study Client server databases with curriculum-aligned Revision Notes resources, practice links, and exam-focused support.
At a glance
revision notes
Resource type
Topic
Client server databases
Revision notes
Client–Server Databases: Concurrent Access and Lost Updates
Client–server database systems
A client–server database system provides simultaneous access to a database for multiple clients. A client is an application or user system requesting data or carrying out an operation, while the server manages access to the shared database. Because several clients may work with the database at the same time, the system must control concurrent access to preserve database integrity.
The lost-update problem
Concurrent access can cause updates to be lost when two clients edit the same record at the same time. For example:
- Client A reads a record containing a quantity of 10.
- Client B also reads the same record containing a quantity of 10.
- Client A changes the quantity to 11 and writes the record back.
- Client B changes its copy to 12 and writes it back.
- The final value is 12, so Client A's update is lost.
The problem occurs because each client works from a value that may no longer be the current value when its update is written. The database may contain a value that does not represent both intended changes, so its integrity has not been preserved.
Methods of controlling concurrent access
Record locks
A record lock restricts access to a record while a client is editing it. If Client A locks a record, Client B cannot simultaneously edit that same record. Client B must wait until the lock is released, so the two updates do not overwrite each other at the same time.
Serialisation
Serialisation controls operations so that concurrent actions are treated in an ordered sequence rather than allowing conflicting edits to proceed without control. If two clients want to update the same record, their operations can be handled one after the other. This avoids an uncontrolled interleaving that could cause an update to be lost.
Timestamp ordering
Timestamp ordering assigns or uses timestamps to determine the order in which client operations are accepted. Conflicting operations are processed according to that ordering, rather than simply being accepted in an uncontrolled order. This provides a way to control concurrent access to the same data.
Commitment ordering
Commitment ordering controls the order in which concurrent operations are committed. Conflicting changes are committed according to an agreed order, helping prevent the database from accepting an inconsistent combination of updates.
Important distinctions
A record lock directly restricts simultaneous access to a particular record. Serialisation, timestamp ordering and commitment ordering are different ways of imposing an order on conflicting concurrent operations. All four approaches address the same underlying concern: preserving database integrity when multiple clients access shared data.
Common errors
- Saying that simultaneous access is always unsafe: the issue is uncontrolled concurrent access, especially when clients edit the same record.
- Confusing a client with the database server: clients request access; the server manages the shared database.
- Claiming that the last write automatically combines both changes: in the lost-update example, the last write can overwrite an earlier update.
- Treating record locks, serialisation, timestamp ordering and commitment ordering as identical terms: they are distinct methods of controlling concurrency.
- Discussing only reading data: the lost-update problem specifically concerns two clients editing a record at the same time.
Related topics
