We've established that the Thomas Write Rule can reduce unnecessary transaction aborts by ignoring obsolete writes. But by how much? Under what conditions? And what are the real-world implications for database system performance?

In this page, we'll quantify the performance improvements achieved by the Thomas Write Rule, examining both theoretical analysis and practical benchmark results. We'll identify the workload characteristics that maximize benefits and understand when the rule provides minimal improvement.

This analysis is crucial for database architects and developers who need to make informed decisions about concurrency control strategies for their specific use cases.

Before measuring improvement, we must understand what's being improved. Transaction aborts are expensive because:

Direct Costs:

1. Wasted CPU Cycles: All computation performed by the aborted transaction must be discarded and re-executed

2. Wasted I/O: Any reads from disk are wasted; data may no longer be in cache on restart

3. Rollback Overhead: If writes were applied before abort, they must be undone using log records

4. Lock Release: Any locks held must be released (may trigger cascading effects)

5. Restart Overhead: Transaction must acquire new timestamp, restart from BEGIN

Indirect Costs:

1. Increased Contention: Restarted transactions compete with concurrent transactions again

2. Cascading Delays: Transactions waiting on the aborted transaction may need to wait longer

3. Reduced Throughput: System capacity is spent on work that produces no output

4. Increased Latency: User-perceived response times increase

Let's develop a mathematical model of the Thomas Write Rule's abort reduction.

Notation:

• P_ww: Probability of write-write conflict (two transactions write to same item)
• P_wr: Probability that a later transaction has read the item (causing actual conflict)
• P_abort_basic: Probability of abort in basic timestamp ordering
• P_abort_thomas: Probability of abort with Thomas Write Rule

Basic Timestamp Ordering:

In basic timestamp ordering, a transaction aborts if:

1. It attempts a read that conflicts with a later write (TS < W-TS), OR
2. It attempts a write that conflicts with a later read (TS < R-TS), OR
3. It attempts a write that conflicts with a later write (TS < W-TS)

With Thomas Write Rule:

Condition 3 is no longer an abort case—it becomes an ignored write. Therefore:

P_abort_thomas = P_abort_basic - P_ww × (1 - P_wr)

Where P_ww × (1 - P_wr) represents the probability of a write-write conflict without intervening read.

Example Calculation:

Consider a workload with:

• 1000 concurrent transactions
• 10,000 data items (hot spot = 100 items accessed by 80% of transactions)
• Each transaction performs 5 writes
• Read/write ratio: 80/20

Step 1: Calculate P_ww

Probability that two specific transactions write to same item:

• Hot spot items: (5 × 0.8 / 100)² ≈ 0.0016 per item pair
• With 100 hot items and many transactions competing: P_ww ≈ 0.15

Step 2: Calculate P_wr

Probability that a read occurred between conflicting writes:

• Depends on timing and read/write ratio
• With 80% reads: P_wr ≈ 0.4

Step 3: Calculate Abort Reduction

Aborts avoided = P_ww × (1 - P_wr)
              = 0.15 × (1 - 0.4)
              = 0.15 × 0.6
              = 0.09 (9% of transactions)

If basic timestamp ordering had a 25% abort rate, the Thomas Write Rule reduces it to approximately 16%—a 36% reduction in aborts.

Reducing aborts translates to improved throughput. Let's analyze the relationship between abort reduction and throughput gain.

Throughput Model:

System throughput (transactions per second) can be modeled as:

Throughput = N / (T_exec × (1 + P_abort × K))

Where:

• N: Number of concurrent transaction slots
• T_exec: Average transaction execution time
• P_abort: Probability of abort
• K: Restart overhead factor (ratio of abort cost to execution time)

Example Analysis:

System parameters:

• N = 100 concurrent transactions
• T_exec = 10 ms
• K = 2 (abort costs twice the execution time)

Key Observations:

1. Throughput improvement is nonlinear — Reducing aborts by 36% yields 14% throughput improvement because the effective execution time is reduced.

2. Resource savings compound — Fewer aborts mean less CPU waste, less I/O waste, and less lock contention.

3. Latency improvement mirrors throughput — Average transaction latency decreases proportionally.

4. Tail latency improves more — The variance in transaction latency decreases because fewer transactions experience abort-restart cycles.

Scalability Effects:

The benefit of Thomas Write Rule often scales with system load:

• At low load: Few conflicts, minimal benefit
• At medium load: Moderate conflicts, significant benefit
• At high load: Many conflicts, substantial benefit (prevents system from degrading)
• At very high load: System bottlenecks may shift to other factors

The Thomas Write Rule's effectiveness varies dramatically based on workload characteristics. Understanding these factors helps predict and optimize performance.

Factor 1: Read/Write Ratio

The read/write ratio determines how many conflicts can benefit from the Thomas Write Rule.

• High read ratio (90% reads): Most conflicts are read-write, which cannot be handled by the rule. Benefit: Minimal
• Balanced (50% reads): Mixed conflict types. Benefit: Moderate
• High write ratio (90% writes): Most conflicts are write-write, maximizing rule applicability. Benefit: Substantial

Factor 2: Data Access Patterns

How transactions access data significantly impacts write-write conflict probability.

Hot Spot Pattern:

• Few items accessed by many transactions
• High conflict probability
• High benefit from Thomas Write Rule
• Example: Counter increments, popular product inventory

Uniform Pattern:

• All items accessed with equal probability
• Low conflict probability
• Lower absolute benefit (fewer conflicts to begin with)
• Example: User profile updates across large user base

Time-Based Pattern:

• Recent items accessed more frequently
• Moderate conflict probability
• Moderate benefit
• Example: Recent order updates, current session data

The Thomas Write Rule isn't free. Let's analyze the overheads that partially offset its benefits.

Overhead 1: Write Buffer Management

To support read-own-write semantics, the system maintains a per-transaction write buffer:

• Memory overhead: Each transaction needs buffer space (typically O(writes per transaction))
• Lookup overhead: Each read must check the buffer before reading from database
• Cleanup overhead: Buffer must be discarded on commit (for ignored writes)

Typical cost: 0.01 - 0.1 ms per operation

Overhead 2: Additional Timestamp Comparison

The W-TS check requires an additional comparison:

• Basic check: if (TS(T) < R-TS(X)) — abort
• Thomas check: if (TS(T) < R-TS(X)) — abort, else if (TS(T) < W-TS(X)) — ignore

Typical cost: < 0.001 ms (negligible)

Overhead 3: Continued Execution of 'Doomed' Transactions

When a write is ignored, the transaction continues. If it performs significant additional work before committing, that work is executed but produces a potentially different final state than if the write had succeeded.

Impact: Application-dependent; usually minimal since the schedule is view serializable

Let's examine benchmark results comparing basic timestamp ordering with the Thomas Write Rule enhancement.

Benchmark Setup:

• Hardware: 8-core CPU, 32 GB RAM, SSD storage
• Database: 1 million rows across 10 tables
• Transactions: Mix of reads and writes, varying ratios
• Concurrency: 10 to 500 concurrent transactions
• Duration: 60 seconds per configuration

Key Observations from Benchmarks:

1. Improvement scales with concurrency: At low concurrency (10 transactions), improvement is minimal because conflicts are rare. At high concurrency (500 transactions), improvement exceeds 40%.

2. Throughput ceiling is higher: Basic TSO plateaus around 71,000 TPS due to abort-restart overhead. Thomas Write Rule reaches 102,000 TPS—a higher sustainable throughput.

3. Abort count reduction is dramatic: At 500 concurrent transactions, over 31,000 aborts per second are avoided—that's significant computational savings.

4. Latency percentiles improve: The 99th percentile latency dropped by 35-50% due to fewer abort-restart cycles affecting unlucky transactions.

Alternative Workload (Read-Heavy):

With 90% reads / 10% writes:

• Improvement drops to 3-5% even at high concurrency
• Most conflicts are read-write, which the rule doesn't help
• Still beneficial, but less dramatically

How does the Thomas Write Rule compare with other approaches to handling write-write conflicts?

Comparison 1: Thomas Write Rule vs Two-Phase Locking (2PL)

2PL handles write-write conflicts by making the second transaction wait for the first to release its lock.

Comparison 2: Thomas Write Rule vs MVCC

MVCC (Multi-Version Concurrency Control) maintains multiple versions of data items to avoid conflicts.

MVCC Approach to Write-Write Conflicts:

• Create new version for each write
• Readers see consistent snapshot
• Writers rarely conflict (each creates own version)
• Garbage collection needed for old versions

Performance Comparison:

When to Choose Each:

• Thomas Write Rule: Simpler systems, write-heavy workloads, limited storage
• MVCC: Complex systems, mixed workloads, read-heavy, need for snapshot isolation

We've comprehensively analyzed the performance improvements provided by the Thomas Write Rule. Let's consolidate the key takeaways:

What's Next:

In the final page of this module, we'll examine the correctness of the Thomas Write Rule in rigorous detail. We'll prove that ignoring obsolete writes maintains view serializability, examine edge cases that could threaten correctness, and discuss the relationship between the rule and database consistency guarantees.