Master the IT-English vocabulary of SQL isolation levels: read committed, repeatable read, serializable, dirty reads and phantoms.
0 / 14 completed
1 / 14
A 'dirty read' occurs when a transaction reads what?
A dirty read sees another transaction's uncommitted data, which could be rolled back and never made permanent.
2 / 14
The 'serializable' isolation level provides what guarantee?
Serializable is the strictest level; results are as if transactions ran sequentially, eliminating anomalies.
3 / 14
A 'phantom read' happens when?
A phantom read sees rows appear (or vanish) between two identical queries due to another transaction's inserts/deletes.
4 / 14
Why might a team choose 'read committed' over 'serializable'?
Lower isolation reduces locking/contention and improves throughput at the cost of some anomalies.
5 / 14
Which sentence correctly uses 'non-repeatable read'?
A non-repeatable read is when re-reading the same row returns a different value because another transaction committed a change.
6 / 14
Alice: 'Hey team, I'm seeing weird results in the user profile service. It seems like a user's address is changing mid-transaction! We're using Read Committed. Any ideas?'
Which of the following best explains Alice's observation and why Read Committed might not be preventing it?
Alice's report highlights a potential Non-Repeatable Read. Read Committed offers the weakest level of isolation: it ensures that a transaction sees data only as it was when the transaction started, *after* any committed changes. However, it doesn't prevent other transactions from modifying the same data concurrently; if another transaction commits an update to the user's address while Alice's transaction is still running, Alice will see this changed value – a non-repeatable read. The options incorrectly assume Read Committed inherently prevents concurrency issues or are simply stating definitions without explaining the practical consequence.
7 / 14
Alice: 'Hey team, I'm seeing weird results in the user profile service. It seems like a user's address is changing mid-transaction! We're using Read Committed. Any ideas?'
Which of the following best explains Alice's observation and why Read Committed might not be preventing it?
Alice's report highlights a potential Non-Repeatable Read. Read Committed offers the weakest level of isolation: it ensures that a transaction sees data only as it was when the transaction started, *after* any committed changes. However, it doesn't prevent other transactions from modifying the same data concurrently; if another transaction commits an update to the user's address while Alice's transaction is still running, Alice will see this changed value – a non-repeatable read. The options incorrectly assume Read Committed inherently prevents concurrency issues or are simply stating definitions without explaining the practical consequence.
8 / 14
Alice: 'Hey team, I'm seeing weird results in the user profile service. It seems like a user's address is changing mid-transaction! We're using Read Committed. Any ideas?'
Which of the following best explains Alice's observation and why Read Committed might not be preventing it?
Alice's report highlights a potential Non-Repeatable Read. Read Committed offers the weakest level of isolation: it ensures that a transaction sees data only as it was when the transaction started, *after* any committed changes. However, it doesn't prevent other transactions from modifying the same data concurrently; if another transaction commits an update to the user's address while Alice's transaction is still running, Alice will see this changed value – a non-repeatable read. The options incorrectly assume Read Committed inherently prevents concurrency issues or are simply stating definitions without explaining the practical consequence.
9 / 14
Alice: 'Hey team, I'm seeing weird results in the user profile service. It seems like a user's address is changing mid-transaction! We're using Read Committed. Any ideas?'
Which of the following best explains Alice's observation and why Read Committed might not be preventing it?
Alice's report highlights a potential Non-Repeatable Read. Read Committed offers the weakest level of isolation: it ensures that a transaction sees data only as it was when the transaction started, *after* any committed changes. However, it doesn't prevent other transactions from modifying the same data concurrently; if another transaction commits an update to the user's address while Alice's transaction is still running, Alice will see this changed value – a non-repeatable read. The options incorrectly assume Read Committed inherently prevents concurrency issues or are simply stating definitions without explaining the practical consequence.
10 / 14
David from the DevOps team just sent a Slack message: 'Just noticed an issue with our inventory service. A user updated their shipping address, and then *immediately* after that, another transaction tried to order something using the old address! We're running Read Committed.' Which isolation level is most likely causing this problem?
Read Committed allows a transaction to see changes made by other concurrent transactions that have been *committed*. However, it doesn't prevent a user from seeing uncommitted data. David's message describes a scenario where the first transaction committed an update, and then the second transaction read that same data before it was finalized – this is precisely how a 'dirty read' occurs with Read Committed isolation levels. The other options—Serializable, Repeatable Read, and Read Uncommitted—offer stronger guarantees against such inconsistencies.
11 / 14
SELECT * FROM orders WHERE customer_id = 123;
This query is executed within a transaction. Another transaction updates the `customer_id` of user 123 to 456, and then commits. What type of read might this first transaction experience?
Non-repeatable reads happen when a transaction re-executes the same query after another transaction has modified data. Because Read Committed is in use, the first transaction might see the *old* value of `customer_id` (123) during its execution and the second transaction sees the updated value (456). This inconsistency demonstrates the vulnerability of non-repeatable reads.
12 / 14
// Code Review Comment: 'Consider using a higher isolation level here. With Read Committed, you could be susceptible to phantom reads if the user's address is updated concurrently.'
A senior developer is suggesting this comment on a database query. What does 'phantom read' most likely refer to?
Phantom reads occur when a transaction retrieves a set of rows based on a condition (e.g., `WHERE customer_id = 123`). If another transaction inserts or deletes rows that satisfy the same condition, the first transaction might see new rows (inserted) or fewer rows (deleted) – even though no changes were made to the original query itself. This is because the 'phantom' rows appear as if they materialized from nowhere.
13 / 14
The team is discussing whether to use Serializable or Read Committed for their core e-commerce transactions. The CTO argues that Read Committed is sufficient due to the relatively low transaction volume and the importance of minimizing locking overhead. What's a primary reason why the CTO's choice might be risky?
Read Committed provides the least restrictive isolation level. While it allows for more concurrency than Serializable, this comes at the expense of potentially experiencing dirty reads. The CTO's argument ignores the possibility of a user updating their address and then another transaction reading that data before the update is finalized – leading to incorrect order processing or other critical business issues. Serializable isolation guarantees consistency but significantly reduces concurrency.
14 / 14
During a Standup meeting, Ben says: 'We're using Non-Repeatable Read for our product recommendations. It seems to be working fine.' What is the *most likely* problem Ben is overlooking?
Non-Repeatable Reads are inherently prone to inconsistency. The core issue is that the same row might be updated by another transaction between the times the initial read and subsequent re-read occur. This can severely impact the accuracy of product recommendations if the recommendation system relies on consistent data – leading to poor suggestions or incorrect pricing.
What does the "Transaction Isolation Levels" exercise practise?
Master the IT-English vocabulary of SQL isolation levels: read committed, repeatable read, serializable, dirty reads and phantoms.
How many questions are in this exercise?
This exercise has 14 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Intermediate. If the vocabulary feels difficult, browse the Database & SQL category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Transaction Isolation Levels" part of a larger series?
Yes — it's one exercise in the Database & SQL category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Database & SQL category page for related exercises, or browse the main Exercises hub for other IT English topics.