79:T1c03,from typing import Dict, List, Set, Tuple, Optional from dataclasses import dataclass, field from enum import Enum class OpType(Enum): READ = "R" WRITE = "W" COMMIT = "C" ABORT = "A" @dataclass class Operation: """Represents a single operation in a schedule.""" transaction: str op_type: OpType data_item: Optional[str] = None timestamp: int = 0 def __repr__(self): if self.data_item: return f"{self.op_type.value}_{self.transaction}({self.data_item})" return f"{self.op_type.value}_{self.transaction}" @dataclass class UnrepeatableReadDetector: """ Detects unrepeatable read anomalies in transaction schedules. An unrepeatable read occurs when: 1. Transaction Ti reads data item X 2. Transaction Tj writes to X 3. Tj commits 4. Ti reads X again (seeing Tj's value) Key distinction from dirty read: Tj must commit before Ti's second read. """ operations: List[Operation] = field(default_factory=list) # Track reads per transaction per item: {txn: {item: [timestamps]}} reads: Dict[str, Dict[str, List[int]]] = field(default_factory=dict) # Track writes: {item: [(txn, timestamp)]} writes: Dict[str, List[Tuple[str, int]]] = field(default_factory=dict) # Track commits: {txn: timestamp} commits: Dict[str, int] = field(default_factory=dict) timestamp: int = 0 def execute(self, operation: Operation) -> None: """Execute an operation and track it.""" operation.timestamp = self.timestamp self.operations.append(operation) self.timestamp += 1 if operation.op_type == OpType.READ: txn = operation.transaction item = operation.data_item if txn not in self.reads: self.reads[txn] = {} if item not in self.reads[txn]: self.reads[txn][item] = [] self.reads[txn][item].append(operation.timestamp) print(f" t={operation.timestamp}: {operation}") elif operation.op_type == OpType.WRITE: item = operation.data_item if item not in self.writes: self.writes[item] = [] self.writes[item].append((operation.transaction, operation.timestamp)) print(f" t={operation.timestamp}: {operation}") elif operation.op_type == OpType.COMMIT: self.commits[operation.transaction] = operation.timestamp print(f" t={operation.timestamp}: {operation}") elif operation.op_type == OpType.ABORT: print(f" t={operation.timestamp}: {operation}") def detect_unrepeatable_reads(self) -> List[Dict]: """ Detect all unrepeatable read anomalies in the schedule. Returns list of anomalies with details about the transactions and data items involved. """ anomalies = [] for txn_i, items_read in self.reads.items(): for item, read_times in items_read.items(): if len(read_times) < 2: continue # Need at least 2 reads for unrepeatable read first_read = read_times[0] for subsequent_read in read_times[1:]: # Check for intervening committed write by another transaction if item not in self.writes: continue for writer_txn, write_time in self.writes[item]: if writer_txn == txn_i: continue # Same transaction, not an anomaly # Check pattern: R1(X) < W2(X) < C2 < R1(X) if writer_txn not in self.commits: continue # Writer didn't commit commit_time = self.commits[writer_txn] if (first_read < write_time < commit_time < subsequent_read): anomalies.append({ "reader": txn_i, "writer": writer_txn, "item": item, "first_read_time": first_read, "write_time": write_time, "commit_time": commit_time, "second_read_time": subsequent_read, }) return anomalies def demonstrate_detection(): """Demonstrate unrepeatable read detection with examples.""" print("=" * 60) print("Example 1: UNREPEATABLE READ PRESENT") print("=" * 60) detector1 = UnrepeatableReadDetector() # Schedule: R1(X), W2(X), C2, R1(X), C1 # T1 reads X, T2 writes & commits X, T1 reads X again detector1.execute(Operation("T1", OpType.READ, "X")) detector1.execute(Operation("T2", OpType.WRITE, "X")) detector1.execute(Operation("T2", OpType.COMMIT)) detector1.execute(Operation("T1", OpType.READ, "X")) detector1.execute(Operation("T1", OpType.COMMIT)) anomalies1 = detector1.detect_unrepeatable_reads() print(f" Anomalies detected: {len(anomalies1)}") for a in anomalies1: print(f" - {a['reader']} experienced unrepeatable read of {a['item']}") print(f" First read at t={a['first_read_time']}, {a['writer']} wrote at " f"t={a['write_time']}, committed at t={a['commit_time']}, " f"second read at t={a['second_read_time']}") print(" " + "=" * 60) print("Example 2: NO UNREPEATABLE READ (Writer doesn't commit in time)") print("=" * 60) detector2 = UnrepeatableReadDetector() # Schedule: R1(X), W2(X), R1(X), C1, C2 # T2 commits AFTER T1's second read detector2.execute(Operation("T1", OpType.READ, "X")) detector2.execute(Operation("T2", OpType.WRITE, "X")) detector2.execute(Operation("T1", OpType.READ, "X")) detector2.execute(Operation("T1", OpType.COMMIT)) detector2.execute(Operation("T2", OpType.COMMIT)) anomalies2 = detector2.detect_unrepeatable_reads() print(f" Anomalies detected: {len(anomalies2)}") if not anomalies2: print(" No unrepeatable reads (T2 committed after T1's second read)") print(" " + "=" * 60) print("Example 3: NO UNREPEATABLE READ (Only one read)") print("=" * 60) detector3 = UnrepeatableReadDetector() # Schedule: R1(X), W2(X), C2, C1 # T1 only reads X once detector3.execute(Operation("T1", OpType.READ, "X")) detector3.execute(Operation("T2", OpType.WRITE, "X")) detector3.execute(Operation("T2", OpType.COMMIT)) detector3.execute(Operation("T1", OpType.COMMIT)) anomalies3 = detector3.detect_unrepeatable_reads() print(f" Anomalies detected: {len(anomalies3)}") if not anomalies3: print(" No unrepeatable reads (T1 only read X once)") if __name__ == "__main__": demonstrate_detection()71:{"json":{"id":"seed_b914a48983c520ef4d61bc3900164d29","slug":"unrepeatable-read-problem","category":"Database Management System","topic":"Concurrency Problems","title":"Unrepeatable Read Problem","description":"Master the unrepeatable read (non-repeatable read) concurrency anomaly in database systems. Understand its formal definition, how it differs from dirty reads and phantoms, examine real-world scenarios where it causes data inconsistency, and learn prevention strategies through isolation levels and locking protocols.","difficulty":"INTERMEDIATE","estimatedMinutes":75,"pages":[{"id":"seed_479382d4dc35ca3b7ef9889c63518007","title":"Unrepeatable Read Definition","order":0,"content":[{"id":"opening-hook","title":"When Data Shifts Beneath Your Feet","content":[{"data":{"content":"Imagine you're a bank customer checking your account balance online. The system shows $5,000. You decide to withdraw $3,000 at an ATM across the street. When you arrive and insert your card, the ATM checks your balance—but now it shows only $2,000. Confused, you return to the website, and it still shows $5,000 on your open session.\n\n**What happened?**\n\nWhile you were walking to the ATM, an automatic payment of $3,000 processed against your account. The ATM saw the updated balance, but your web session—still running the same transaction—continued to show the old value. Within the *same logical transaction*, you observed two different values for the same data item.\n\nThis is the **unrepeatable read problem**: a concurrency anomaly where a transaction reads the same data item twice and gets different values because another transaction modified and committed the data between the reads. It's not a bug in your application—it's a fundamental challenge in concurrent database access."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the formal definition of unrepeatable reads, the precise timing conditions that cause them, how they differ from dirty reads and phantom reads, and why they violate the isolation property of ACID transactions.","variant":"info"},"type":"callout"}]},{"id":"formal-definition","title":"Formal Definition","content":[{"data":{"content":"An **unrepeatable read** (also called a **non-repeatable read** or **fuzzy read**) occurs when a transaction reads the same data item multiple times and observes different values due to modifications by other committed transactions between the reads.\n\n**Formal Definition:**\n\n> An unrepeatable read occurs when transaction T₁ reads a data item X, then transaction T₂ modifies and commits X, and subsequently T₁ reads X again—observing T₂'s committed value instead of the value it originally read.\n\nSymbolically, the problematic sequence is:\n\n```\nT₁: R(X) → value v₁\n T₂: W(X) → value v₂\n T₂: COMMIT\nT₁: R(X) → value v₂ (different from v₁!)\nT₁: COMMIT\n```\n\nThe key characteristics that define an unrepeatable read are:"},"type":"text"},{"data":{"items":["**Same data item**: The transaction reads the *exact same* row or record twice (not different rows matching a condition)","**Same transaction**: Both reads occur within the same transaction boundary (between BEGIN and COMMIT/ROLLBACK)","**Intervening modification**: Another transaction modifies the data between the two reads","**Committed modification**: The modifying transaction commits before the second read (this distinguishes it from dirty reads)","**Different values observed**: The two reads return different values for the same data item"],"title":{"icon":"Target","text":"Defining Characteristics","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"Info","title":"The 'Committed' Distinction","content":"The modifying transaction must have committed for this to be an unrepeatable read. If T₂ modifies X but hasn't committed, and T₁ reads the modified value, that's a **dirty read**—a different (and generally more severe) problem. Unrepeatable reads involve only committed data, which makes them paradoxically harder to detect: the data is technically 'valid' at each read.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"timing-window","title":"The Timing Window","content":[{"data":{"content":"Understanding when unrepeatable reads can occur requires examining the precise timing relationships between transactions. The vulnerability window exists between a transaction's first and subsequent reads of the same data item.\n\n**The Vulnerable Interval:**\n\nWhen transaction T₁ reads data item X at time t₁, and plans to read X again at time t₂, the interval [t₁, t₂] represents the window during which another transaction could modify X and cause an unrepeatable read."},"type":"text"},{"data":{"rows":[["t₀","BEGIN","","100","X = 100 (initial)"],["t₁","R(X) → 100","","100","T₁ sees 100"],["t₂","...processing...","BEGIN","100","T₂ starts"],["t₃","...processing...","W(X) ← 200","100→200","T₂ writes 200 (uncommitted)"],["t₄","...processing...","COMMIT","200","T₂ commits, X = 200 permanent"],["t₅","R(X) → 200 ⚠️","","200","T₁ sees 200 (different!)"],["t₆","COMMIT","","200","T₁ commits with inconsistent view"]],"caption":"Timeline of an Unrepeatable Read","headers":["Time","T₁ (Reader)","T₂ (Writer)","X Value","State"]},"type":"table"},{"data":{"content":"**Critical Observations:**\n\n1. **At t₁**: T₁ reads X = 100. This is its \"snapshot\" of reality.\n\n2. **Between t₁ and t₅**: T₂ successfully modifies and commits X = 200. The database is now in a new consistent state.\n\n3. **At t₅**: T₁ reads X again and sees 200. From T₁'s perspective, the same data item magically changed value.\n\n4. **The paradox**: Both values (100 and 200) were valid committed values at the time they were read. T₁ isn't reading \"wrong\" data—it's reading data from two different points in time.\n\nThe fundamental issue is that T₁ doesn't operate on a consistent snapshot of the database. It sees the database at time t₁ for its first read and at time t₅ for its second read."},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Wider the Window, the Greater the Risk","content":"The probability of an unrepeatable read increases with the time gap between reads. Long-running transactions that read the same data multiple times are especially vulnerable. A transaction that reads a value, performs complex calculations for several seconds, then reads again has ample opportunity for intervening commits by other transactions.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"distinguishing-anomalies","title":"Distinguishing from Related Anomalies","content":[{"data":{"content":"Unrepeatable reads are one of three read-related anomalies in concurrent database systems. Understanding how they differ is crucial for selecting appropriate isolation levels and designing robust transactions.\n\n**The Three Read Anomalies:**"},"type":"text"},{"data":{"rows":[["**Dirty Read**","Value of existing row","Uncommitted transaction","Single row"],["**Unrepeatable Read**","Value of existing row","Committed transaction","Single row"],["**Phantom Read**","Set of rows matching query","Committed transaction","Query result set"]],"caption":"Comparison of Read Anomalies","headers":["Anomaly","What Changes","Data Source","Scope"]},"type":"table"},{"data":{"left":[{"data":{"items":["T₁ reads **uncommitted** data from T₂","T₂ might rollback, invalidating T₁'s read","Reads data that may never \"exist\"","Violates isolation at a fundamental level","Prevented by: READ COMMITTED or higher"],"title":{"icon":"XCircle","text":"Dirty Read (Different Problem)","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["T₁ reads **committed** data that later changes","Both reads see valid committed values","Reads data that did exist (but changed)","Violates repeatable read expectation","Prevented by: REPEATABLE READ or higher"],"title":{"icon":"AlertCircle","text":"Unrepeatable Read (This Topic)","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"**Phantom Read vs. Unrepeatable Read:**\n\nThe distinction between unrepeatable reads and phantom reads is subtle but important:"},"type":"text"},{"data":{"rows":[["**What's affected**","A specific row that was previously read","The set of rows matching a query condition"],["**Operation type**","UPDATE or DELETE to an existing row","INSERT or DELETE affecting query results"],["**Example**","Row with ID=5 changes from balance=100 to balance=200","Query for balance>1000 returns 3 rows, then 5 rows"],["**Lock required**","Row-level lock on specific rows","Predicate lock or range lock on query condition"]],"headers":["Aspect","Unrepeatable Read","Phantom Read"]},"type":"table"},{"data":{"content":"**Why the distinction matters:**\n\nPreventing unrepeatable reads requires locking specific rows that have been read. Preventing phantom reads requires locking potential rows that *might* be read—rows that don't yet exist or that match a condition. This makes phantom prevention significantly more complex and expensive."},"type":"text"},{"data":{"icon":"Lightbulb","title":"Memory Aid","content":"Think of it this way: **Dirty reads** see tentative futures (uncommitted changes). **Unrepeatable reads** see the changing present (committed changes between reads). **Phantom reads** see shifting populations (new or removed rows matching conditions). Unrepeatable reads are about the *value* of identified rows changing; phantoms are about *which* rows exist.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"acid-violation","title":"Why This Violates ACID","content":[{"data":{"content":"The ACID properties define the guarantees that database transactions should provide. Unrepeatable reads directly violate the **Isolation** property, with indirect implications for **Consistency**.\n\n**The Isolation Violation:**\n\nThe 'I' in ACID guarantees that concurrent transactions execute as if they were serialized—running one after another with no overlap. In a truly isolated system, transaction T₁ should not be affected by T₂'s concurrent modifications.\n\nUnrepeatable reads violate this because:\n\n1. **T₁ observes T₂'s effects mid-transaction**: Isolation should hide T₂'s changes until T₁ completes\n2. **T₁ sees partial database evolution**: Some reads see pre-T₂ state, others see post-T₂ state\n3. **No equivalent serial schedule**: T₁ sees a state that would never occur if transactions ran sequentially"},"type":"text"},{"data":{"items":["**Isolation (Direct)**: T₁ is not isolated from T₂'s committed changes. The interleaved execution produces results that couldn't occur in any serial execution of T₁ and T₂.","**Consistency (Indirect)**: If T₁'s logic depends on stable values (e.g., an invariant that two reads match), the transaction may violate application-level consistency constraints.","**Atomicity (Preserved)**: Each transaction still succeeds or fails as a unit—unrepeatable reads don't affect atomicity.","**Durability (Preserved)**: Committed data remains durable—unrepeatable reads don't affect persistence."],"title":{"icon":"AlertCircle","text":"ACID Properties Affected","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"content":"**The Serial Equivalence Test:**\n\nConsider what happens if T₁ and T₂ ran serially:\n\n**Serial Order T₁ → T₂:**\n```\nT₁: BEGIN, R(X)=100, R(X)=100, COMMIT\nT₂: BEGIN, W(X)=200, COMMIT\nResult: T₁ sees X=100 both times (consistent)\n```\n\n**Serial Order T₂ → T₁:**\n```\nT₂: BEGIN, W(X)=200, COMMIT \nT₁: BEGIN, R(X)=200, R(X)=200, COMMIT\nResult: T₁ sees X=200 both times (consistent)\n```\n\n**But with unrepeatable read:**\n```\nT₁ sees X=100 first, then X=200\nThis matches neither serial order!\n```\n\nThe concurrent execution produces a result impossible under serial execution—the definition of an isolation violation."},"type":"text"},{"data":{"icon":"Info","title":"Isolation Levels as a Tradeoff","content":"Database systems provide multiple isolation levels precisely because full isolation (SERIALIZABLE) reduces concurrency. Levels like READ COMMITTED intentionally allow unrepeatable reads to improve performance. The key is understanding what you're trading away and whether your application can tolerate the anomaly.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"read-stability","title":"Read Stability Expectation","content":[{"data":{"content":"The unrepeatable read problem violates what database theorists call **read stability**—the expectation that data read during a transaction remains stable for the transaction's duration.\n\n**What Read Stability Means:**\n\n> A schedule provides read stability for transaction T if every data item X that T reads retains its value throughout T's execution.\n\nThis is a natural expectation for most programmers. If you read a variable's value in a program, you expect it to have that value until you explicitly change it. Databases that allow unrepeatable reads break this intuition.\n\n**Why Read Stability Matters:**"},"type":"text"},{"data":{"items":["**Broken assertions**: Code that caches query results may hold stale data, leading to incorrect decisions","**Inconsistent calculations**: Multi-step computations using the same data may mix old and new values","**Failed validations**: Checks performed at the start of a transaction may not hold at the end","**Violated invariants**: Business rules that depend on relationships between data items may be violated","**Non-deterministic behavior**: The same transaction code may produce different results depending on concurrent activity"],"title":{"icon":"Target","text":"Implications of Lost Read Stability","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**Example: The Broken Transfer:**\n\n```sql\n-- Transaction T₁: Verify and transfer\nBEGIN;\nSELECT balance INTO @balance FROM accounts WHERE id = 1;\n-- @balance = 1000\n\n-- Meanwhile T₂ runs: UPDATE accounts SET balance = 500 WHERE id = 1; COMMIT;\n\n-- T₁ continues, unaware of the change\nIF @balance >= 500 THEN\n -- Check passes, but actual balance is now 500, not 1000\n \n SELECT balance INTO @current_balance FROM accounts WHERE id = 1;\n -- @current_balance = 500 (different!)\n \n UPDATE accounts SET balance = balance - 500 WHERE id = 1;\n -- This creates an overdraft: 500 - 500 = 0 (or negative if T₂ withdrew more)\nEND IF;\nCOMMIT;\n```\n\nThe transaction made a decision based on one value (1000) but executed based on another (500). Read stability would have prevented this inconsistency."},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Illusion of Caching","content":"A common mistake is caching query results in application variables and assuming they remain valid. Without read stability at the database level, these cached values become dangerous lies. Either re-read with proper isolation, use explicit locking, or design logic that doesn't depend on value stability.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"formal-notation","title":"Formal Notation and Detection","content":[{"data":{"content":"To rigorously analyze and detect unrepeatable reads, we need formal notation for representing transaction schedules. This notation enables precise reasoning about when anomalies occur.\n\n**Schedule Notation:**\n\n- **Rᵢ(X)**: Transaction Tᵢ reads data item X\n- **Wᵢ(X)**: Transaction Tᵢ writes data item X\n- **Cᵢ**: Transaction Tᵢ commits\n- **Aᵢ**: Transaction Tᵢ aborts\n\n**Formal Pattern for Unrepeatable Read:**\n\nA schedule contains an unrepeatable read if there exists transactions Tᵢ and Tⱼ such that:\n\n```\nRᵢ(X) < Wⱼ(X) < Cⱼ < Rᵢ(X)\n```\n\nWhere `<` denotes \"precedes in the schedule.\" In words:\n1. Tᵢ reads X\n2. Tⱼ writes X (after Tᵢ's first read)\n3. Tⱼ commits (making the write permanent)\n4. Tᵢ reads X again (seeing Tⱼ's committed value)"},"type":"text"},{"data":{"fileName":"unrepeatable_read_detector.py","languages":[{"code":"$79","label":"Python","value":"python"}]},"type":"code"},{"data":{"icon":"Lightbulb","title":"Detection vs. Prevention","content":"Detection algorithms like the one shown are primarily for analysis and testing. In production systems, prevention (through appropriate isolation levels or locking) is preferred over detection because detecting an unrepeatable read after it occurs may be too late—the transaction may have already made incorrect decisions based on inconsistent data.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"read-phenomena-hierarchy","title":"Read Phenomena Hierarchy","content":[{"data":{"content":"The three read anomalies form a hierarchy based on their severity and the isolation level required to prevent them. Understanding this hierarchy is essential for choosing appropriate database configurations.\n\n**The Hierarchy (from most to least severe):**\n\n```\nDirty Read ⊃ Unrepeatable Read ⊃ Phantom Read\n```\n\nThis means:\n- Preventing dirty reads also helps prevent conditions that could lead to more severe isolation violations\n- Preventing unrepeatable reads requires at least as much protection as preventing dirty reads, plus additional guarantees\n- Preventing phantoms requires the strongest protection"},"type":"text"},{"data":{"rows":[["READ UNCOMMITTED","Possible","Possible","Possible"],["READ COMMITTED","**Prevented**","Possible","Possible"],["REPEATABLE READ","**Prevented**","**Prevented**","Possible*"],["SERIALIZABLE","**Prevented**","**Prevented**","**Prevented**"]],"caption":"SQL Isolation Levels and Read Phenomena","headers":["Isolation Level","Dirty Read","Unrepeatable Read","Phantom Read"]},"type":"table"},{"data":{"content":"**Note on REPEATABLE READ and Phantoms:**\n\nThe SQL standard states that REPEATABLE READ may allow phantom reads. However, implementations vary:\n\n- **PostgreSQL**: REPEATABLE READ uses snapshot isolation, which prevents phantoms in most cases\n- **MySQL InnoDB**: Uses next-key locking which prevents many phantom scenarios\n- **SQL Server**: May allow phantoms unless additional locking hints are used\n\n**Why REPEATABLE READ Prevents Unrepeatable Reads:**\n\nThe REPEATABLE READ isolation level ensures that any row read during a transaction will return the same value if read again within that same transaction. This is typically implemented through:\n\n1. **Locking approach**: Hold read locks until transaction end\n2. **MVCC approach**: Read from a consistent snapshot taken at transaction start"},"type":"text"},{"data":{"icon":"Info","title":"Implementation Matters","content":"The SQL standard defines minimum guarantees, but implementations often provide stronger guarantees. Always consult your specific database's documentation to understand exactly which anomalies are prevented at each isolation level.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: Unrepeatable Read Definition","content":[{"data":{"content":"We've established a rigorous understanding of what unrepeatable reads are and how they fit into the landscape of concurrency anomalies. Let's consolidate the key concepts:"},"type":"text"},{"data":{"type":"ordered","items":["**Definition**: An unrepeatable read occurs when a transaction reads the same data item twice and gets different values because another transaction modified and committed the data between reads.","**Committed Data**: Unlike dirty reads, unrepeatable reads involve only committed data—both read values were valid at their respective times.","**Timing Condition**: The pattern is R₁(X) < W₂(X) < C₂ < R₁(X)—a write and commit by T₂ interleaved between T₁'s reads.","**Isolation Violation**: Unrepeatable reads violate the ACID Isolation property because the transaction observes changes from concurrent transactions mid-execution.","**Read Stability**: The anomaly breaks the expectation that data remains stable throughout a transaction.","**Prevention**: REPEATABLE READ or SERIALIZABLE isolation levels prevent unrepeatable reads."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's next:**\n\nNow that we understand the formal definition of unrepeatable reads, we'll explore the broader concept of **inconsistent reads**—how unrepeatable reads can combine with other data access patterns to create complex inconsistency scenarios that affect transaction correctness and application logic."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the precise definition of unrepeatable reads, can distinguish them from dirty reads and phantom reads, and know which isolation levels prevent them. Next, we'll examine how inconsistent reads manifest in more complex scenarios and why they create challenges for application correctness.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_7bbb9a0c9a6dec4b7c5a9d12ceacc150","title":"Inconsistent Reads","order":1,"content":null,"isLocked":true},{"id":"seed_ff7767af8e3749a303f0ee923b657d1b","title":"Example Scenario","order":2,"content":null,"isLocked":true},{"id":"seed_d9a7975e390053da1077f3f32812c984","title":"Business Impact","order":3,"content":null,"isLocked":true},{"id":"seed_b7db6f023a48af2ca95feecea2ea061b","title":"Prevention","order":4,"content":null,"isLocked":true}]}}