s5.07.07 - client-server databases and concurrency
Master client-server database architecture, concurrent access challenges, and multi-user data integrity.
Have you ever bought the last concert ticket online, only for it to be 'unavailable' a second later? Or seen two people try to book the same holiday cottage simultaneously? Welcome to the chaotic world of concurrent database access! Today, we'll explore how modern systems cope when millions of users interact with the same data at once, why this causes huge problems for data accuracy, and how architects design client-server databases to keep things orderly.
Learning Outcomes
Factual (Knowing that)
Conceptual (Knowing why)
Procedural (Knowing how)
Recall the definition of a client-server database architecture.
Describe the concept of concurrent access in a database system.
State specific types of concurrency problems, such as the lost update problem.
Conceptual (Knowing why)
Analyse how multi-user concurrent access introduces challenges to data integrity.
Explain why the client-server model is essential for managing data in enterprise-scale applications.
Distinguish between the roles of the client and the server in a database system.
Procedural (Knowing how)
Apply knowledge of concurrent operations to identify potential lost update scenarios in a given sequence of events.
Create a simple diagram illustrating the flow of data in a client-server database.
The Deep Dive
Client-Server Databases and the Challenge of Concurrency
The Client-Server Database Architecture
In modern enterprise applications, data is rarely stored on a single user's computer. Instead, a client-server database architecture is employed. This model involves:
Clients: These are user applications (e.g., a web browser, a mobile app, a desktop program) that send requests for data or data modifications. Each client runs on a separate machine, typically a user's device.
Server: This is a powerful central computer that hosts the Database Management System (DBMS) and the actual database files. The server processes all client requests.
When a client needs data, it sends a request across a network to the server. The DBMS on the server then retrieves or modifies the data and sends a response back to the client. This centralisation of data and processing logic is fundamental for modern, scalable information systems.
Simultaneous Access: A Double-Edged Sword
A primary benefit of the client-server model is allowing many users (clients) to access and modify the same data simultaneously. This is called concurrent access. Imagine hundreds of customers booking flights on an airline website at the same time, or multiple bank tellers processing transactions.
While essential for business operations, unmanaged concurrent access introduces significant risks to data integrity. Data integrity ensures that data remains accurate, complete, and consistent. When multiple users read and write the same data at overlapping times, their operations can interfere with each other, leading to incorrect or lost data.
The Perils of Concurrency: Lost Updates
One of the most common and critical concurrency problems is the lost update problem. This occurs when two or more transactions (sequences of operations, often initiated by different users) concurrently update the same data item, and the update of one transaction overwrites (is "lost" by) the update of another.
Consider a simple banking scenario:
1
Initial State: An account has a balance of £100.
2
User A (Transaction 1): Reads the balance (£100).
3
User B (Transaction 2): Reads the balance (£100) - at roughly the same time as User A.
4
User A (Transaction 1): Adds £50 to the balance, calculating a new balance of £150.
5
User B (Transaction 2): Adds £20 to the balance, calculating a new balance of £120.
6
User A (Transaction 1): Writes the new balance (£150) back to the database.
7
User B (Transaction 2): Writes the new balance (£120) back to the database.
In this scenario, User A's update (£50) is completely overwritten and "lost". The final balance of £120 is incorrect, as it should be £170. This directly violates data integrity. Other problems, such as "dirty reads" (where one transaction reads uncommitted changes from another, which are then rolled back), can also occur.
So, why Client-Server then?
Despite these challenges, the client-server model is indispensable for several reasons:
Centralised Control: All data resides on a single server, making it easier for Database Administrators to manage security, backups, and ensure data consistency.
Scalability: The server can be upgraded independently to handle more users and larger datasets without affecting client applications.
Security: Access to the raw database files can be restricted to the server, with the DBMS controlling user permissions and auditing all operations.
Concurrency Management: Crucially, the DBMS is designed to implement sophisticated mechanisms (like those we'll see in the next lesson) to detect and prevent concurrency problems, ensuring that even with simultaneous access, data remains accurate and reliable.
The DBMS acts as a traffic controller, ensuring that conflicting operations are managed in a way that preserves data integrity. Without it, the "chaos" of concurrent access would make many modern applications impossible.
Don't just accept the text. Write down three high-level 'Why' or 'What if' questions about these notes that aren't explicitly answered here. Use these to challenge your teacher or guide your independent study.
Comprehension Questions
Answer these questions on your lesson sheet.1
Define a client-server database architecture and identify its two main components.
2
What is meant by 'concurrent access' in a database system?
3
Describe the 'lost update problem' using a simple example.
4
Explain one benefit of using a client-server database model for an enterprise like an online banking system.
5
How does simultaneous access, without proper controls, threaten the data integrity of a database?
Task Spotting Concurrency Chaos
Welcome, junior Database Administrator! A busy online ticket booking platform, "EventFlow", is experiencing intermittent issues. Customers are complaining about tickets disappearing after they've bought them, or seeing incorrect availability. You suspect problems due to concurrent access. Your mission is to analyse several scenarios and identify where data integrity is at risk. This task will make you think like a Software Architect designing robust systems!
0
Get Organised!
Read through the scenarios below.
On your lesson sheet, create a table with three columns: 'Scenario Number', 'Concurrency Problem Identified', and 'Impact on Data Integrity'.
1
Analyse the Ticket Booking Scenario (Trace and Identify)
EventFlow uses a
TicketsEventIDTicketTypeAvailableStockCurrent
AvailableStockScenario 1
Time 0: User A reads
AvailableStockTime 1: User B reads
AvailableStockTime 2: User A tries to buy 2 VIP tickets. System calculates new stock (10 - 2 = 8).
Time 3: User B tries to buy 3 VIP tickets. System calculates new stock (10 - 3 = 7).
Time 4: User A updates
AvailableStockTime 5: User B updates
AvailableStockOn your lesson sheet, for Scenario 1:
State the final
AvailableStockIdentify the specific concurrency problem that occurred.
Explain the impact on data integrity and why the final stock is incorrect.
2
Identify Potential Conflicts (Conceptual Application)
For each of the following scenarios at EventFlow, identify if a concurrency problem is likely, and if so, what kind. Explain why and its impact on data integrity.
Scenario 2: Two EventFlow administrators simultaneously try to change the
GenreScenario 3: A user attempts to book tickets for 'EventID F100'. At the same time, another administrator is deleting 'EventID F100' because it has been cancelled. The user successfully completes the booking, but the event no longer exists in the
tblEventsScenario 4: EventFlow's analytics system generates a daily report on 'Total Tickets Sold'. While the report is running, customer service processes a large refund for 50 tickets. The report finishes before the refund transaction is fully committed.
3
Propose Simple Conceptual Solutions
For each identified problem in Scenarios 1-4, suggest a simple conceptual approach (without using technical terms like 'locking' or 'ACID', which we'll cover next lesson) that the DBMS could use to prevent such data integrity issues. For example, for Scenario 1: The system could make sure that only one user can access (read and then write) the
AvailableStock
Hungry for more?
Search the web: database concurrency control problems solutions
Ask an AI: Click on the carefully written prompt below to learn more...
Role: Senior Database Architect. Task: Explain the precise operational mechanisms of the 'dirty read' concurrency problem in multi-user databases, contrasting it with the 'lost update' problem. Length: Under 180 words. Audience: A-Level Computer Science student. Tone: Rigorous, academic, and objective. Constraints: Use a concrete commercial example and bullet points for the two anomalies. NO intro, NO outro, NO deviation from the topic, NO follow-up questions.
Research Deadlock: Research the concept of 'deadlock' in databases and describe a scenario where it might occur.
Outcome: A comprehensive analysis of concurrency issues in the EventFlow online shop scenario, with suggested conceptual solutions to prevent data integrity problems.
Sticky Note Challenge
Write down the definition of a lost update and one way it could affect your favourite online game.
Last modified: October 21st, 2026
