SSZG518:
BITS Pilani
Pilani Campus
Database design and
Applications
Prof. Uma Maheswari
BITS Pilani
Pilani Campus
Session 8,9
Concurrency to Query Processing
TUTORIAL
Concurrency and LOCKS
BITS Pilani, Pilani Campus
Concurrency control manager
Isolation
• This property ensures that multiple transactions can occur simultaneously without
causing any inconsistency.
• During execution, each transaction feels as if it is getting executed alone in the
system.
• A transaction does not realize that there are other transactions executed in parallel
• Changes made by a transaction becomes visible to other transactions only after they
are written in the memory.
• The resultant state of the system after executing all the transactions is same as the
state that would be achieved if the transactions were executed serially one after the
other.
• It is the responsibility of concurrency control manager to ensure isolation for all
the transactions.
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
Different 2-phase locking protocols
BITS Pilani, Pilani Campus
Check what 2-phase lock?
Lock_S(A)
R(A)
Lock_X(B)
R(A)
R(B)
B=A+B
Unlock(A)
W(B)
Unlock(B)
Lock_S(A)
R(A)
Lock_X(B)
Unlock(A)
R(B)
W(B)
commit
Unlock(B)
Lock_S(A)
R(A)
Unlock(A)
Lock_X(B)
R(B)
W(B)
Unlock(B)
commit
BITS Pilani, Pilani Campus
LOCKS in MYSQL
mysql> LOCK TABLES t1 READ;
mysql> SELECT COUNT(*) FROM t1;
+----------+ | COUNT(*) | +----------+ | 3 | +----------+
mysql> LOCK TABLES t2 WRITE;
mysql> SELECT COUNT(*) FROM t2;
ERROR 1100 (HY000): Table 't2' was not locked with
LOCK TABLES
SET autocommit=0;
LOCK TABLES t1 WRITE, t2 READ
…do something with tables t1 and t2 here
...
COMMIT;
UNLOCK TABLES;
mysql> LOCK TABLE t WRITE, t AS t1 READ;
mysql> INSERT INTO t SELECT * FROM t;
ERROR 1100: Table 't' was not locked with LOCK TABLES
mysql> INSERT INTO t SELECT * FROM t AS t1;
BITS Pilani, Pilani Campus
Locks in Mysql
Row level locking
Connection 2
Connection 1
UPDATE accDetails SET ledgerAmount = ledgerAmount + 250 WHERE id=2;
1 row(s) affected
START TRANSACTION; SELECT ledgerAmount FROM accDetails WHERE id = 1 FOR
UPDATE;
row level lock obtained by SELECT ... FOR UPDATE statement.
Connection 2
But while updating some other row in connection 2 will be executed without any
error.
Connection 1
UPDATE accDetails SET ledgerAmount = ledgerAmount + 750 WHERE id=1; COMMIT; 1 row(s)
affected
UPDATE accDetails SET ledgerAmount = ledgerAmount + 500 WHERE id=1;
When some one try to update same row in connection 2, that will
wait for connection 1 to finish transaction or error message will
be displayed according to the innodb_lock_wait_timeout setting,
which defaults to 50 seconds.
Error Code: 1205. Lock wait timeout exceeded; try restarting transaction
To view details about this lock, run SHOW ENGINE INNODB STATUS
Now row lock is released, because transaction is commited in Connection 1.
Connection 2
UPDATE accDetails SET ledgerAmount = ledgerAmount + 500 WHERE id=1; 1 row(s) affected
The update is executed without any error in Connection 2 after Connection 1
released row lock by finishing the transaction.
When two sessions or users of database try to
update or delete the same data in a table, then
there will be a concurrent update problem. In
order to avoid this problem, database locks
the data for the first user and allows him to
update/delete the data.
BITS Pilani, Pilani Campus
Isolation levels for transaction:
SET TRANSACTION ISOLATION LEVEL
{ READ UNCOMMITTED
| READ COMMITTED
| REPEATABLE READ
| SNAPSHOT
| SERIALIZABLE
}
BITS Pilani, Pilani Campus
Examples
Let's write a transaction without Isolation level.
1.BEGIN TRANSACTION MyTransaction
2.BEGIN TRY
3.UPDATE Account SET Debit=100 WHERE Name='John Cena'
4.UPDATE ContactInformation SET Mobile='1234567890' WHERE Name='The Rock'
5.COMMIT TRANSACTION MyTransaction
6.PRINT 'TRANSACTION SUCCESS'
7.END TRY
8.BEGIN CATCH
9.ROLLBACK TRANSACTION MyTransaction
10.PRINT 'TRANSACTION FAILED'
11.END CATCH
the transaction can read uncommitted data resulting in the Dirty Read problem. With this isolation level, we allow a
transaction to read the data which is being updated by other transaction and not yet committed.
1.SET TRANSACTION ISOLATION LEVEL
2.READ UNCOMMITTED
3.BEGIN TRANSACTION MyTransaction
4.BEGIN TRY
5.UPDATE Account SET Debit=100 WHERE Name='John Cena'
6.UPDATE ContactInformation SET Mobile='1234567890' WHERE Name='The Rock'
7.COMMIT TRANSACTION MyTransaction
8.PRINT 'TRANSACTION SUCCESS'
9.END TRY
10.BEGIN CATCH
11.ROLLBACK TRANSACTION MyTransaction
12.PRINT 'TRANSACTION FAILED'
13.END CATCH
prevents Dirty Read. When this level is set, the transaction can not read the data
that is being modified by the current transaction. This will force user to wait for the
current transaction to finish up its job.
1.SET TRANSACTION ISOLATION LEVEL
2.READ COMMITTED
3.BEGIN TRANSACTION MyTransaction
4.BEGIN TRY
5.UPDATE Account SET Debit=100 WHERE Name='John Cena'
6.UPDATE ContactInformation SET Mobile='1234567890' WHERE Name='The Rock'
7.COMMIT TRANSACTION MyTransaction
8.PRINT 'TRANSACTION SUCCESS'
9.END TRY
10.BEGIN CATCH
11.ROLLBACK TRANSACTION MyTransaction
12.PRINT 'TRANSACTION FAILED'
13.END CATCH
BITS Pilani, Pilani Campus
Timestamp ordering protocol
Rule No. 01 is used when any transaction wants to
Basic TO Protocol
perform Read(A) operation
•Not Allowed
• R1(X) W2(X)
If WTS(A) > TS (Ti), then Ti Rollback
• W1(X) R2(X)
Else (otherwise) execute R(A) operation and SET RTS (A) = MAX
• W1(X) W2(X)
{RTS(A), TS(Ti)}
•Allowed
• All operations where T2 occurs before T1.
Rules No.2 is used when a transaction needs to perform WRITE (A)
• R1(X) R2(X)
If RTS(A) > TS (Ti), then Ti Rollback
If WTS(A) > TS (Ti), then Ti Rollback
Else (otherwise) execute W(A) operation and SET WTS (A) =
TS(Ti)
Where “A” is some data
Let's assume there are two transactions T1 and T2.
Suppose the transaction T1 has entered the system at
007 times and transaction T2 has entered the system at
009has
times.
T1
the higher priority, so it executes first as it is entered
the system first.
BITS Pilani, Pilani Campus
Example of Timestamp ordering Protocol
Rule No. 01 is used when any transaction
wants to perform Read(A) operation
If WTS(A) > TS (Ti), then Ti Rollback
Else (otherwise) execute R(A) operation
and SET RTS (A) = MAX {RTS(A), TS(Ti)}
Rules No.2 is used when a transaction
needs to perform WRITE (A)
If RTS(A) > TS (Ti), then Ti Rollback
If WTS(A) > TS (Ti), then Ti Rollback
Else (otherwise) execute W(A) operation
and SET WTS (A) = TS(Ti)
Where “A” is some data
BITS Pilani, Pilani Campus
Thomas Write Rule:
Thomas Write Rule does not enforce Conflict
Serializability but rejects fewer Write
Operations by modifying the check
Operations for W_item(X)
If R_TS(X) > TS(T), then abort and roll back T and
reject the operation.
If W_TS(X) > TS(T), then don’t execute the Write
Operation and continue processing. This is a case of
Outdated or Obsolete Writes. Remember, outdated
writes are ignored in Thomas Write Rule but a
Transaction following Basic TO protocol will abort
such a Transaction.
If neither the condition in 1 or 2 occurs, then and only
then execute the W_item(X) operation of T and set
W_TS(X) to TS(T)
Thomas Write Rule
•Not Allowed
• R1(X) W2(X)
• W1(X) R2(X)
•Allowed
• All operations where T2 occurs before
T 1.
• Outdated Writes: W1(X) W2(X)
• R1(X) R2(X)
Thomas Write rule doesn’t allow conflict serializable schedule but only allows “view
serializable” schedules!!!
BITS Pilani, Pilani Campus
Is this allowed Thomas write rule or not?
BITS Pilani, Pilani Campus
Multi granularity locking protocol
The multiple granularity locking (MGL) protocol consists of the
following rules:
1. The lock compatibility (based on Figure 22.8) must be adhered to.
2. The root of the tree must be locked first, in any mode.
3. A node N can be locked by a transaction T in S or IS mode only if
the parent node N is already locked by transaction T in either IS or IX
mode.
4. A node N can be locked by a transaction T in X, IX, or SIX mode
only if the parent of node N is already locked by transaction T in
either IX or SIX mode.
5. A transaction T can lock a node only if it has not unlocked any node
(to enforce the 2PL protocol).
6. A transaction T can unlock a node, N, only if none of the children of
node N are currently locked by T.
Rule 1 simply states that conflicting locks cannot be granted. Rules 2, 3,
and 4 state the conditions when a transaction may lock a given node in
any of the lock modes. Rules 5 and 6 of the MGL protocol enforce 2PL
rules to produce serializable schedules.
BITS Pilani, Pilani Campus
Example: MGLP
BITS Pilani, Pilani Campus
Locking in Sqlserver
shared lock on the database level that is
imposed whenever a transaction is connected
to a database.
Locks will always be acquired
from the top to the bottom as in
that way SQL Server is preventing
a so-called Race condition to
occur.
Not all lock modes can be
applied at all levels.
At the row level, the following three lock
modes can be applied:
•Exclusive (X)
•Shared (S)
•Update (U)
DML statement (i.e. insert, update, delete) a shared
lock (S) will be imposed on the database level, an
intent exclusive lock (IX) or intent update lock (IU)
will be imposed on the table and on the page level,
and an exclusive or update lock (X or U) on the row
At the table level, there are five different types of locks:
•Exclusive (X)
•Shared (S)
•Intent exclusive (IX)
•Intent shared (IS)
•Shared with intent exclusive (SIX)
BITS Pilani, Pilani Campus
Deadlocks
BITS Pilani, Pilani Campus
Summary
 Concurrency
 Concurrent protocols
 Deadlock and recovery
BITS Pilani, Pilani Campus
RECOVERY
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
DB SECURITY
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
Problem
BITS Pilani, Pilani Campus
Problem
BITS Pilani, Pilani Campus
Problem
BITS Pilani, Pilani Campus
Problem
BITS Pilani, Pilani Campus
QUERY PROCESSING
BITS Pilani, Pilani Campus
Estimate size (=cardinality) in a bottom-up
fashion
– This is the most difficult part, and still inadequate in
today’s query optimizers
• Estimate cost by using the estimated size
– Hand-written formulas, similar to those we used for
computing the cost of each physical operator
BITS Pilani, Pilani Campus
Cost-based Query Optimization¶
• Given alternate query trees, find the lowest cost
one.
• We do not really need to generate all possible query
trees, but find:
•
•
•
All potential access paths for selections (indices and table scans)
Join orderings that combine these access paths with specific join
implementations
Estimate the cost of a partial query plan and eliminate other plans
that can never be cheaper.
Database Statistics¶
•Compute database statistics regarding each table. This can be
accomplished using the Analyze command in SQL.
•Simplest statistics:
• TUPLES(R): the number of tuples in R
• PAGES(R): the number of pages R spans
• N_DISTINCT(R.A): the number of distinct values stored
for R.A
• MINVAL(R.A)/MAXVAL(R.A): min/max values stored for
R.A
• To be able to estimate the cost of query plans, we
need to know:
•
•
Cardinality estimation: How many tuples we expect as the output of
joins and selections
Space estimation: The size of the tuples on disk to estimate how
many disk pages are needed to store them.
BITS Pilani, Pilani Campus
Query Processing
Branch(bname,bcity,assets)
Account(ano,bname,balance)
Deposit(cname,ano)
Find names of all customers who has account at ‘Chennai’ city and who has balance >10,0000
BITS Pilani, Pilani Campus
Query Plan
The cost of the join is
1000 + 1000 * 500 = 501, 000 page I/Os.
The selections and the projection are done
on-the-fly and do not incur
additional I/Os.
Ignore the cost of writing out the nal result.
The total cost of this plan is therefore 501,000
page I/Os.
BITS Pilani, Pilani Campus
Problem
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
REVIEW and EXAM RULES
1.
2.
3.
4.
5.
Transactions
Concurrency control, LOCKS, DEADLOCKS
RECOVERY
DB SECURITY
QUERY PROCESSING
BITS Pilani, Pilani Campus
THANK YOU
BITS Pilani, Pilani Campus