Michael's First Blog

Concurrency and Locking

JANUARY 13, 2013 BY MICHAEL HENRY

i Rate This This chapter discusses how to allow multiple users to access the same database at the same time without interfering with each other, and keeping their operations consistent. We will discuss the concepts of concurrency and locking. Concurrency implies that several users can work at the same time on the same database objects. DB2 was designed as a multi-user database. Access to data must be coordinated properly and transparently using a mechanism to ensure data integrity and consistency.

Now, look at this picture:

(http://hwkeren.files.wordpress.com/2013/01/38.jpg) There are four applications, App A, App B, App C, and App D that are trying to access the same row (row 2) in a table. Without any concurrency control, all of the applications could perform operations against the same row. Assuming all of the applications are updating the Age column for row 2 with different values, the application which performs the update the last will likely be the winner in this situation. It should be obvious in this example that some sort of concurrency control is required to guarantee consistent results. This concurrency control is based on using locks. Locking temporarily stops other applications from performing their operation until another operation finishes. The more locking there is in a system, the less concurrency is possible. On the other hand, the less locking there is in a system, the more concurrency is possible. Locks are acquired automatically as needed to support a transaction and are released when the transaction terminates (using either a COMMIT or ROLLBACK command). Locks can be acquired on tables or rows. There are two basic types of locks: Share locks (S locks) Share locks acquired when an application wants to read and prevent others from updating the same row. Exclusive locks (X locks)

Exclusive locks acquired when an application updates, inserts, or deletes a row. If you using locks on the example above, the picture will be like this

(http://hwkeren.files.wordpress.com/2013/01/39.jpg) For example, if App B is the first one accessing row 2, and is performing an UPDATE, App B holds an X lock on the row. When App A, App C and App D try to access the same row, they wont be able to UPDATE it because of the X lock. This control allows for consistency and integrity of the data. Without some form of concurrency control, the following problems may be encountered: Lost update Uncommitted read Non-repeatable read Phantom read Lets discuss the problem one by one. a. Lost update Lost update is a problem similar to the one explained earlier in this section where the application performing the last update, will be the winner. For example

(http://hwkeren.files.wordpress.com/2013/01/40.jpg) In the picture, you can see there are two applications attempting to update the same row. The one on the left is application App1, and the one on the right is application App2. The sequence of events is: 1. 2. 3. 4. App1 updates a row App2 updates the same row App1 commits App2 commits

The result : App1s update is lost when App2 make its update, hence the term Lost Update. b. Uncommitted read An uncommitted read, or dirty read allows for an application to read information that has not been committed, and therefore is not necessarily accurate. For example

(http://hwkeren.files.wordpress.com/2013/01/41.jpg) The sequence of events is: 1. App1 updates a row 2. App2 reads the new value from that row 3. App1 rolls back its changes to that row The result: App2 is reading uncommitted data, and hence invalid data, which is why this problem is called an uncommitted read. c. Non-repeatable read A non-repeatable read implies that you cannot obtain the same result after performing the same read in the same operation. For example

(http://hwkeren.files.wordpress.com/2013/01/42.jpg)

The sequence of events is: 1. 2. 3. 4. App1 opens a cursor (also known as a result set) obtaining what you see in the picture App2 deletes a row that qualified for the cursor (for example, the row with destination San Jose) App2 commits changes App1 closes and reopens the cursor

The result: App1 would not get the same data on a repeated read, it cannot reproduce the data set; thats why this problem is called non-repeatable read. d. Phantom read The phantom read problem is similar to the non-repeatable read problem, but the difference is that on subsequent fetches, you may obtain additional rows rather than fewer rows. For example

(http://hwkeren.files.wordpress.com/2013/01/43.jpg) The sequence of events is: 1. 2. 3. 4. App1 opens a cursor App2 adds a row to the database that would qualify for the cursor App2 commits changes App1 closes and reopens cursor

The result: App1 would not get the same data on a repeated read, it would get more rows, thats why this problem is called phantom read. So, how do we avoid all the problem above? DB2 provides different levels of protection to isolate data: Uncommitted Read (UR) Cursor Stability (CS) Read Stability (RS) Repeatable Read (RR) i. Uncommitted Read (UR) Uncommitted read is also known as dirty read. It is the lowest level of isolation, and provides the highest degree of concurrency. No row locks are obtained on read operations, unless another application attempts to drop or alter a table; and update operations act as if using the cursor stability isolation level. Problems still possible with this isolation level: Uncommitted read Non-repeatable read Phantom read Problems prevented with this isolation level: Loss of update ii. Cursor Stability (CS) Cursor stability is the default isolation level. It provides a minimal degree of locking.

Basically, with this isolation level the current row of a cursor is locked. If the row is only read, the lock is held until a new row is fetched or the unit of work is terminated. If the row is updated, the lock is held until the unit of work is terminated. Problems still possible with this isolation level: Non-repeatable read Phantom read Problems prevented with this isolation level: Loss of update Uncommitted read iii. Read Stability (RS) With read stability, all the rows an application retrieves within a unit of work are locked. For a given cursor, it locks all rows that qualify for the result set. For example, if you have a table containing 10,000 rows and the query returns 10 rows, then only those 10 rows are locked. Read stability uses a moderate degree of locking. Problems still possible with this isolation level: Phantom read Problems prevented with this isolation level: Loss of update Uncommitted read Non-repeatable read iv. Repeatable Read (RR)

Repeatable read is the highest isolation level. It provides the highest degree of locking, and the least concurrency. Locks are held on all rows processed to build the result set; that is, rows not necessarily in the final result set may be locked. No other application can update, delete, or insert a row that would affect the result set until the unit of work completes. Repeatable read guarantees that the same query issued by an application more than once in a unit of work will give the same result each time. Problems still possible with this isolation level: none Problems prevented with this isolation level: Loss of update Uncommitted read Non-repeatable read Phantom read For more detail, you can watch this video: Concurrency & Locking (http://www.youtube.com/watch?v=1FzLEJfCN_o&feature=youtu.be) DB2 LEAVE A COMMENT BLOG AT WORDPRESS.COM. | THE SOMETHING FISHY THEME. Follow

Follow Michael's First Blog

Powered by WordPress.com