Coding for concurrency
•Download as PPTX, PDF•
0 likes•286 views
The document discusses concurrency issues that can occur when multiple transactions access the same data simultaneously. It describes different types of concurrency problems like lost updates, dirty reads, unrepeatable reads, and phantom reads. It then discusses how locking can be used to control concurrency and ensure transactional integrity. Finally, it outlines different isolation levels from lowest to highest that control the balance between concurrency and data correctness.
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Coding for concurrency
- 1. CODING FOR CONCURRENCY 1063035 – 1063103 - 1603154
- 2. database At the same time… …at the same data
- 3. Problem?!Problems Lost updates Dirty read Unrepeatble read Phantom reads
- 4. Lost updates time transaction 10 9 8 7 6 5 4 3 2 1 Commit tran Write(A’’) Read(A) Begin tran lost data Read(A) Begin tran Write(A’) Commit tran
- 5. Dirty read time 10 9 8 7 6 5 4 3 2 1 Begin tran Write(A) If(error) Rollback tran Commit tran Begin tran Read(A) Commit tran Data has been changed transaction
- 6. Unrepeatable read time 10 9 8 7 6 5 4 3 2 1 transaction Begin tran Read(A) Read(A) Commit tran Begin tran Commit tran Write(A) Data A (changed) Data A (original)
- 7. Phantom reads time 10 9 8 7 6 5 4 3 2 1 transaction Write(B) Begin tran Commit tran Begin tran Commit tran Read(A) Read(A,B) Data range (changed) Data range (original)
- 9. LOCKING use locking to ensure transactional integrity and database consistency
- 10. Lock mode SHARED UPDATE EXCLUSIVE INTENT SCHEMA BULK UPDATE Read-only operations (select statement)Used on resources that can be updatedUsed for data-modification operationsUsed to establish a lock hierarchyUsed when an operation dependent on the schema of a table is executingUsed when bulk-copying data into a table and the TABLOCK hint is specified
- 11. Shared locks (S) Data rowSHARED modification
- 13. Exclusive locks (S) Data rowSHARED Modify or Read
- 14. Intent locks (S) Intent shared (IS) Intent exclusive (IX) Shared with intent exclusive (SIX)
- 15. Schema locks (S) Schema modification locks (Sch-M) Schema stability locks (Sch-M) used when a table data definition language (DDL) operation is being performed. used when compiling queries
- 16. Bulk Update locks (S) data copying
- 17. ISOLATION When locking is used as the concurrency control mechanism, it solves concurrency problems. This allows all transactions to run in complete isolation of one another, although there can be more than one transaction running at any time.
- 20. Isolation level Dirty read Nonrepeatable read Phantom Read uncommitted (lowest) Yes Yes Yes Read committed No Yes Yes Repeatable read No No Yes Serializable (highest) No No No
Editor's Notes
- Lost updates occur when two or more transactions select the same row and then update the row based on the value originally selected. Each transaction is unaware of other transactions. The last update overwrites updates made by the other transactions, which results in lost data.
- Uncommitted dependency occurs when a second transaction selects a row that is being updated by another transaction. The second transaction is reading data that has not been committed yet and may be changed by the transaction updating the row.
- nconsistent analysis occurs when a second transaction accesses the same row several times and reads different data each time. Inconsistent analysis is similar to uncommitted dependency in that another transaction is changing the data that a second transaction is reading. However, in inconsistent analysis, the data read by the second transaction was committed by the transaction that made the change. Also, inconsistent analysis involves multiple reads (two or more) of the same row and each time the information is changed by another transaction; thus, the term nonrepeatable read.
- Phantom reads occur when an insert or delete action is performed against a row that belongs to a range of rows being read by a transaction. The transaction's first read of the range of rows shows a row that no longer exists in the second or succeeding read, as a result of a deletion by a different transaction. Similarly, as the result of an insert by a different transaction, the transaction's second or succeeding read shows a row that did not exist in the original read.
- Locking prevents users from reading data being changed by other users, and prevents multiple users from changing the same data at the same time. If locking is not used, data within the database may become logically incorrect, and queries executed against that data may produce unexpected results.
- Shared (S) Used for operations that do not change or update data (read-only operations), such as a SELECT statement. Update (U) Used on resources that can be updated. Prevents a common form of deadlock that occurs when multiple sessions are reading, locking, and potentially updating resources later.Exclusive (X) Used for data-modification operations, such as INSERT, UPDATE, or DELETE. Ensures that multiple updates cannot be made to the same resource at the same time. Intent Used to establish a lock hierarchy. The types of intent locks are: intent shared (IS), intent exclusive (IX), and shared with intent exclusive (SIX). Schema Used when an operation dependent on the schema of a table is executing. The types of schema locks are: schema modification (Sch-M) and schema stability (Sch-S). Bulk Update (BU) Used when bulk-copying data into a table and the TABLOCK hint is specified.
- Shared (S) locks allow concurrent transactions to read (SELECT) a resource. No other transactions can modify the data while shared (S) locks exist on the resource. Shared (S) locks on a resource are released as soon as the data has been read, unless the transaction isolation level is set to repeatable read or higher, or a locking hint is used to retain the shared (S) locks for the duration of the transaction.
- Deadlock is a condition that can occur on any system with multiple threads, not just on a relational database management system. A thread in a multi-threaded system may acquire one or more resources (for example, locks). If the resource being acquired is currently owned by another thread, the first thread may have to wait for the owning thread to release the target resource. The waiting thread is said to have a dependency on the owning thread for that particular resource.To avoid this potential deadlock problem, update (U) locks are used. Only one transaction can obtain an update (U) lock to a resource at a time. If a transaction modifies a resource, the update (U) lock is converted to an exclusive (X) lock. Otherwise, the lock is converted to a shared-mode lock.
- Exclusive (X) locks prevent access to a resource by concurrent transactions. No other transactions can read or modify data locked with an exclusive (X) lock.
- Schema modification (Sch-M) locks are used when a table data definition language (DDL) operation (such as adding a column or dropping a table) is being performed. Schema stability (Sch-S) locks are used when compiling queries. Schema stability (Sch-S) locks do not block any transactional locks, including exclusive (X) locks. Therefore, other transactions can continue to run while a query is being compiled, including transactions with exclusive (X) locks on a table. However, DDL operations cannot be performed on the table.
- Bulk update (BU) locks are used when bulk copying data into a table and either the TABLOCK hint is specified or the table lock on bulk load table option is set using sp_tableoption. Bulk update (BU) locks allow processes to bulk copy data concurrently into the same table while preventing other processes that are not bulk copying data from accessing the table.