ibm - Informix-Concurrency-and-Locking

  • Published on
    25-Nov-2014

  • View
    110

  • Download
    1

Embed Size (px)

Transcript

Information Management Informix

RDBMS Fundamentals: Concurrency and LockingTransaction Concurrency Control and Locking (examples on Informix Dynamic Server)

1

03/21/2011

2009 IBM Corporation 2009 IBM Corporation

Information Management Informix

ObjectivesAt the end of this training session, you will be able to: Understand the need for Concurrency Control mechanisms Understand Locks and types of locks Understand how locking affects performance Understand Isolation Levels Understand the criteria to tune the locking: the different concurrency controls the Lock granularity/mode on a table the Lock Wait Mode/Time of a session/transaction the Isolation Level of a session/transaction Identify Informix configuration parameters that affect locking Identify potential locking issues, including dirty reads, phantom reads, nonrepeatable reads, and deadlocks

2

2009 IBM Corporation

Information Management Informix

Transactions Review A transaction is a program (sequence of statements) that takes a database from one consistent state to another consistent state Transactions have the ACID properties: A Atomicity C Consistency I Isolation the operation sequence is either executed completely or not at all the operation sequence takes the database from any consistent state to another consistent state (correct, integrity) intermediate states of transactions are not visible to other transactions (equivalence to each user feeling they are alone using the database as in single user mode) effects of completed transactions are not lost due to hardware or software failures

D Durability

3

2009 IBM Corporation

Information Management Informix

Transactions Isolation Isolation means that Multiple transactions running at the same time not impact each others execution Each user has the impression that he/she has exclusive access for the entire transaction All other transactions that happen at the same time should appear either as before or after it Like in a Serial schedule of transactions Dirty read / Read Uncommitted Last committed read (Optimistic) Committed read Cursor stability Serializable Repeatable read

Isolation level defines how deep transactions isolate from one another

If DBMS provides concurrency control support for transactions, users/programmers do not need to worry that there are other transactions running at the same time or not

4

2009 IBM Corporation

Information Management Informix

Need for Concurrency Control Isolation (+ Consistency) => Concurrency Control Multiple transactions may want to access and modify the same resources Whenever multiple processes share resources there is need to schedule the access Concurrency control: takes care that transactions access database items (database, table, page, row, index key) such that the meaningful results are produced produces a schedule of database operations from transactions running concurrently so the order of operations for each particular transaction is preserved

5

2009 IBM Corporation

Information Management Informix

Transaction Schedule By Example Assume that Transaction T1 has operations O1 O2 O3

Assume that Transaction T2 has operations P1 P2 P3

O1O2P1O3P2P3 is a schedule

O1P1O3P2P3O2 is not a schedule order is not preserved operation O3 must be executed after O2 within T2

6

2009 IBM Corporation

Information Management Informix

Serial Schedule Schedule is serial if all operations from one transaction are completed prior to beginning of another transaction

Each serial schedule is considered correct since one transaction is independent of the other transactions There is no overlapping of transactions

7

2009 IBM Corporation

Information Management Informix

Serial Schedule Examples and Main Problem In the example on the right: Transactions T1 and T2 update totally different items of the database (X,Y) Hence, T1 and T2 could have been executed concurrently (in parallel) Serial schedules are always correct but do not use computer resources on optimal way (for concurrency and performance)

8

2009 IBM Corporation

Information Management Informix

How To Improve Efficiency? Non-serial schedules Allow transactions to occur at the same time (concurrently) Operations of one transaction can be executed before another transaction is committed Schedules where transactions occur concurrently are called non-serial schedules or concurrent schedules

9

2009 IBM Corporation

Information Management Informix

Non-Serial Schedule Example and New Problems If operations are not meaningfully ordered, we can get unexpected results

Typical problems with schedules: Dirty read Non-repeatable read Phantom read

10

2009 IBM Corporation

Information Management Informix

Dirty Read Problem and Example A Dirty Read occurs because transaction T2 sees the uncommitted results of transaction T1 Transaction T1 reads an item and updates it Transaction T2 reads updated item Transaction T1 might abort in the future (and its update would be annulled) In meantime, transaction T2 proceeds with the item that now has incorrect / uncommitted value Expected (good) behavior if the transactions were serialized: Once T1 is aborted, T2 will still use the old (valid, non-updated) value of the item

11

2009 IBM Corporation

Information Management Informix

Non-Repeatable Read Problem and Example A Nonrepeatable Read occurs if transaction T1 retrieves a different result from the each read Transaction T1 reads an item Transaction T2 reads and updates the same item Transaction T1 reads the same item again, but now it has a new, modified value Expected (good) behavior if the transactions were serialized: If a transaction only reads (and does not modify) the item, each time the item is read, the same value will be obtained

12

2009 IBM Corporation

Information Management Informix

Phantom Read Problem and Example A Phantom Read occurs if transaction T1 obtains a different result from each Select for the same criteria Transaction T1 executes search on certain criteria and retrieve m items from a table Transaction T2 inserts another item that would match the search criteria Transaction T1 again executes search and now retrieves m+1 items from the table Expected (good) behavior if the transactions were serialized: The first and the second search within the same transaction will give the same result

13

2009 IBM Corporation

Information Management Informix

Introducing Locking

Locking is very important in a multi-user DBMS Locking allows one user to work with a data item without another user changing the data item's value Locking is necessary for maintaining data integrity while concurrent users access database information

14

2009 IBM Corporation

Information Management Informix

Locks Lock is implemented as a variable associated to a data item

Can be placed explicitly by the program, or implicitly by the DBMS

Lock describes status of an item with respect to operations that can be performed on the item

Locks types:

Shared locks: multiple users can read an item at the same time Exclusive locks: only one user can read an item at the same time Promotable (Update) lock: A lock can upgrade (from shared to exclusive) or downgrade (vice versa) Intent lock: Placed at the table level, to indicate a cursor is working on the rows of the table

15

2009 IBM Corporation

Information Management Informix

Lock types (1) Share lock (lock-S) Share locks can be placed on objects that do not have an exclusive lock already placed on them Prevents others from updating the data But still, others can read the data (others can place S-locks on it) More than one share lock can be placed on the same object at the same time Exclusive locks can only be placed on rows that do not have any other kind of lock (not even S-lock) on it Once an exclusive lock is placed on a row, no other locks (not even S-locks) can be placed on the same row anymore Prevents others from reading or updating the data 16 2009 IBM Corporation

Exclusive lock (lock-X)

Information Management Informix

Lock types (2) Update lock (lock-U) Used in Update Cursors Update locks are created by cursors that have the for update extension specified and can only be placed on a row that doesnt already have an exclusive or update lock on it The update lock is converted to an exclusive lock as soon as the row is actually updated Intent locks are automatically set by IDS If a row in a table is updated, an exclusive lock is placed on the row and an intent-exclusive lock is placed on the table This ensures that no other session could place a share or exclusive lock on the table as long as an individual row is locked exclusively

Intent lock (lock-IX or IS)

17

2009 IBM Corporation

Information Management Informix

Lock Compatibility Matrix

If the item already has a lock of type

Can I place a lock of type?

18

2009 IBM Corporation

Information Management Informix

Duration of a Lock The program controls the duration of a database lock A database lock is released when the database closes Depending on whether the database uses transactions, table lock durations vary If the database does not use transactions (no transaction log exists and you do not use a COMMIT WORK statement), an explicit

Recommended

View more >