05.11.2015 Views

Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

238<br />

CHAPTER 7 ■ CONCURRENCY AND MULTI-VERSIONING<br />

Table 7-5. Continued<br />

Time Query Account Transfer Transaction<br />

T5<br />

T6<br />

T7<br />

T8<br />

Reads row 342,023, sees $100.00, <strong>and</strong><br />

presents final answer.<br />

Commits transaction.<br />

Updates row 1 <strong>and</strong> puts an exclusive lock<br />

on this block. Row 1 now has $100.00.<br />

Updates row 342,023 <strong>and</strong> puts an exclusive<br />

lock on this block. Row 342,023 now<br />

has $500.00. Commits transaction.<br />

Table 7-5 shows that we now get the correct answer, but at the cost of physically blocking<br />

one transaction <strong>and</strong> executing the two transactions sequentially. This is one of the side effects<br />

of shared read locks for consistent answers: readers of data will block writers of data. This is in<br />

addition to the fact that, in these systems, writers of data will block readers of data. Imagine if<br />

automatic teller machines (ATMs) worked this way in real life.<br />

So, you can see how shared read locks would inhibit concurrency, but they can also cause<br />

spurious errors to occur. In Table 7-6, we start with our original table, but this time with the<br />

goal of transferring $50.00 from account 987 to account 123.<br />

Table 7-6. Timeline 2 in Non-<strong>Oracle</strong> <strong>Database</strong> Using READ REPEATABLE Isolation<br />

Time Query Account Transfer Transaction<br />

T1<br />

T2<br />

T3<br />

Reads row 1. Sum = $500.00 so far.<br />

Block 1 has a shared read lock on it.<br />

Reads row 2. Sum = $740.25 so far.<br />

Block 2 has a shared read lock on it.<br />

T4 Reads row N. Sum = . . .<br />

T5<br />

T6<br />

Attempts to read row 342,023 but cannot<br />

as an exclusive lock is already in place.<br />

Updates row 342,023 <strong>and</strong> puts an<br />

exclusive lock on block 342,023,<br />

preventing other updates <strong>and</strong> shared<br />

read locks. This row now has $50.00.<br />

Attempts to update row 1 but is blocked.<br />

Transaction is suspended until it can<br />

obtain an exclusive lock.<br />

We have just reached the classic deadlock condition. Our query holds resources the<br />

update needs <strong>and</strong> vice versa. Our query has just deadlocked with our update transaction.<br />

One of them will be chosen as the victim <strong>and</strong> will be killed. We just spent a lot of time <strong>and</strong><br />

resources only to fail <strong>and</strong> get rolled back at the end. This is the second side effect of shared<br />

read locks: readers <strong>and</strong> writers of data can <strong>and</strong> frequently will deadlock each other.<br />

As we have seen in <strong>Oracle</strong>, we have statement-level read consistency without reads blocking<br />

writes or deadlocks. <strong>Oracle</strong> never uses shared read locks—ever. <strong>Oracle</strong> has chosen the<br />

harder-to-implement but infinitely more concurrent multi-versioning scheme.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!