Date post: | 06-Apr-2018 |
Category: |
Documents |
Upload: | srigayatri-rachakonda |
View: | 221 times |
Download: | 0 times |
of 41
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
1/41
RDBMS - Day6
OLTP basics, Concurrency, Data integrity, Security
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
2/41
ER/CORP/CRS/DB07/003
Version No: 2.02Copyright 2004,
Infosys Technologies Ltd
Agenda
Transactions
Data integrity & Security
Concurrency control
In todays session, we would be talking about the basic concepts of transactions, online transaction
processing, database integrity, security features using DDL statements, the concept of serializabilityof transactions and about concurrent transactions.+
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
3/41
ER/CORP/CRS/DB07/003
Version No: 2.03Copyright 2004,
Infosys Technologies Ltd
Transaction
Logical unit of program execution that takes a database from one consistent
state to another consistent state
In other words, a transaction is a sequence of database actions which must either all be done, or none of themmust be done.
if only some of the actions of a transaction are carried out the database will be left in an inconsistent state
Consider the example transaction of a transfer of funds between bank accounts
Suppose there are two bank accounts, A and B
The balance in A is Rs 1000 and that in Y is 5000
The transaction has to transfer rs100 from bank account A into bank account B.
The sequence of actions would be:
Read balance in A 1000
Calculate A transfer amount 900
Store new value of A 900
Read balance of B 5000
Calculate B + transfer amount 5100
Store new value of B 5100
If only the steps till 3 are done, then database would be in an inconsistent state
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
4/41
ER/CORP/CRS/DB07/003
Version No: 2.04Copyright 2004,
Infosys Technologies Ltd
ACID Properties
Atomicity
Consistency
Isolation Durability
Atomicity- Transaction management
DBMS keeps track of the old value of a data on which the transaction acts so that, if there isa failure, the old value of the data is restored as though no transaction acted on it
`
Consistency-Application programmer
To ensure that the database remains consistent after execution of the transaction
Isolation-Concurrency control
To ensure concurrent execution of transactions results in a state equivalent to thatobtained by sequential execution
Durability-Recovery management
To ensure that after successful transaction completion, all updates persist irrespective ofsystem failures
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
5/41
ER/CORP/CRS/DB07/003
Version No: 2.05Copyright 2004,
Infosys Technologies Ltd
active
partiallycompleted
failed
abortedcommitted
State diagram of a transaction
While executing
Afterthe
final
statem
enth
as
been
exe
cute
d
When normalexecution cant
proceed
After rollbackand
restoration toprev state
Aftersuccessfulcompletion
Transaction state
Active
Partially committed
Failed
Aborted
Committed
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
6/41
ER/CORP/CRS/DB07/003
Version No: 2.06Copyright 2004,
Infosys Technologies Ltd
SQL and Transactions
BEGIN TRANSACTION
COMMIT TRANSACTION;
ROLLBACK TRANSACTION
A transaction is typically represented by a combination of the above three operations in SQL
The COMMIT statement defines the end of a transaction
The ROLLBACK statement undoes all of the actions of a transaction. Consider the following example
Begin transaction is not standard. A new transaction begins immediately after a commit statement
COMMIT;
Update AccountSet Balance = Balance - 100
Where AccountNo = 11111;
Update Account
Set Balance = Balance + 100
Where AccountNo = 22222;
COMMIT;
COMMIT;
Update Account
Set Balance = Balance - 1000
Where AccountNo = 11111;
Update Account
Set Balance = Balance + 100
Where AccountNo = 22222;ROLLBACK;
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
7/41
ER/CORP/CRS/DB07/003
Version No: 2.07Copyright 2004,
Infosys Technologies Ltd
On-line Transaction Processing Systems
Handle
Several concurrent transactions from
Spatially Distributed M/cs
Execution of Instructions and Queries across LAN/WAN
Geographically distributed processors
Spatially Distributed Databases
Several concurrent transactions are initiated from spatially distributed terminals.
Each transaction has the need for executing several machine instructions, retrievals, updates, and
sending or receiving messages.
Processors distributed geographically execute the programs initiated by these transactions.
There may be one or more databases which may be spatially distributed and used by thetransaction.
Typical examples are: Railway reservation, Bank transactions etc.
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
8/41
ER/CORP/CRS/DB07/003
Version No: 2.08Copyright 2004,
Infosys Technologies Ltd
Data Integrity
Refers to :
Correctness and completeness of data
Validity of individual items
Preservation of interrelationships in the DB
Data integrity constraints:
Required data
Domain integrity
Entity integrity
Referential integrity
To preserve correctness of data, any RDBMS imposes data integrity constraints. These constraints
restrict the data values that can be inserted / modified. The constraints commonly found in RDBMSsare as found in the slide.
We will discuss in detail about these constraints in the following slides..
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
9/41
ER/CORP/CRS/DB07/003
Version No: 2.09Copyright 2004,
Infosys Technologies Ltd
Required data
Requires a column to contain Non-NULL values
Indicated with the key word NOT NULL in create statement
An example:
CREATE TABLE EMPLOYEE (
EMP_NO integer NOT NULL,
EMP_NAME varchar (15) ,
EMP_AGE integer,
.
An insert into the table without a value for the column with NOT NULL constraint fails
An update trying to set the value of the column to a NULL value fails
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
10/41
ER/CORP/CRS/DB07/003
Version No: 2.010Copyright 2004,
Infosys Technologies Ltd
Domain Integrity-Check constraint
Specify a range of values that a column can take.
Used to specify business rules. Specified in the create statement
An example:
CREATE TABLE EMPLOYEE (
EMP_NO integer NOT NULL,
.
EMP_LOC varchar(15)
CHECK ( EMP_LOC in ( BANGALORE,
BOMBAY,DELHI)));
Check constraint is like a search condition. This will produce a true/false value. The condition
specified in the check constraint is verified by the RDBMS for every insert and update operations. Ifany violation is observed, the operation fails.
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
11/41
ER/CORP/CRS/DB07/003
Version No: 2.011Copyright 2004,
Infosys Technologies Ltd
Entity Integrity
The database models the outside world
A tables primary key should have unique values so that it representssome real world entity
The requirement that the primary key be unique is called Entity integrityconstraint
When a primary key is defined on a table, DBMS automatically checks to see if any duplicates are
entered, whenever an insert or update is attempted on the table. If any duplicate is found , theoperation fails with an error message.
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
12/41
ER/CORP/CRS/DB07/003
Version No: 2.012Copyright 2004,
Infosys Technologies Ltd
Referential integrity
Ensures that the integrity of the parent-child relationship between tables
created by primary and foreign keys is preserved
Issues:
Inserting a new child row
Updating foreign key in a child row
Updating the primary key in a parent row
Deleting a parent row
Let us take the first issue: inserting a new child row:
When we try to insert a row in the child table, its foreign key value must be the same as one of the primary key values in a parent table. Forexample, The deptno is a foreign key in the employee table which refers to the dept# in the department table. let us say, we try to insert arow in the employee table, with a department number which is not there in the department table, then it indicates the data is wrong. So ,such a insert should not be allowed. Databases take care of this situation automatically
A similar check is performed when we try to modify the foreign key field
The last two issues are similar:Updating /deleting the parent row. Let us say, we are dissolving a department altogether, what will happen to the eployees who belong to the
department?
Ve to do one of the following:
1. Prevent the dept being deleted until all its employees are reallotted to some other dept
2. Automatically delete the employees who belong to the dept
3. Set the dept column for the employees who belong to the dept to NULL
4. Set the dept column of these employees to some default value which indicates they are currently not allotted to any dept
To achieve this, 4 options can be set in CREATE table command:
ON DELETE RESTRICT
ON DELETE SET NULL
ON DELETE SET DEFAULT
ON DELETE SET CASCADE
For ex:
CREATE table ORDERS
( Order_Num Integer NOT NULL,
.
Foreign key (Cust) REFERENCES Customers
ON DELETE CASCADE,
Foreign key (Rep) REFERENCES SalesReps
ON DELETE SET NULL,
ON UPDATE CASCADE,
Foreign key (Mfr, Product)
REFERENCES Products
ON DELETE RESTRICT
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
13/41
ER/CORP/CRS/DB07/003
Version No: 2.013Copyright 2004,
Infosys Technologies Ltd
Security
Protection of data against unauthorized disclosure, alteration or
destruction.
Access allowed to only authorized users
User identification - Authorized users connect to the database usinguser id and password.
Views, Synonyms,Roles
Access Privileges
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
14/41
ER/CORP/CRS/DB07/003
Version No: 2.014Copyright 2004,
Infosys Technologies Ltd
GRANT .. TO
REVOKE .. FROM ...
Data Definition Language statements for Datasecurity
GRANT & REVOKE
Privileges on a specified database
Privileges on specified tables or views
System privileges
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
15/41
ER/CORP/CRS/DB07/003
Version No: 2.015Copyright 2004,
Infosys Technologies Ltd
GRANT {
[DBADM[, ]] -Database administrator authority
[DBCTRL[,]] -Database control authority[DBMAINT[, ]] -Database maintenance authority
[CREATETAB[,]] -Privilege to create table
[DROP[, ]] -Privilege to DROP/ALTER
[STARTDB[, ]] - Start database
[STOPDB[, ]] } - Stop database
ON DATABASE database-name[,...]
TO [AuthID][,...]
[PUBLIC]
[WITH GRANT OPTION]
1. GRANT . database
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
16/41
ER/CORP/CRS/DB07/003
Version No: 2.016Copyright 2004,
Infosys Technologies Ltd
GRANT {
[ALTER[, ]]
[DELETE[, ]][INDEX[, ]]
[INSERT[, ]]
[SELECT[, ]]
[UPDATE [(column-name[,...])][, ]]
[REFERENCES[, ]]
| ALL [PRIVILEGES] }
ON [TABLE] {table-name[,...] | view-name[,...]}
TO [AuthID][,...]
[PUBLIC [AT ALL LOCATIONS]]
[WITH GRANT OPTION]
2. GRANT . Tables or views
Privileges on a specific table or a view created based on a table.
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
17/41
ER/CORP/CRS/DB07/003
Version No: 2.017Copyright 2004,
Infosys Technologies Ltd
GRANT{
[CREATEALIAS[, ]] - create alias
[CREATEDBA[, ]] - create DB to get DBADM authority
[CREATEDBC[, ]] - create DB to get DBCTRL authority
[CREATESG[, ]] - to create new storage group
[SYSADM[, ]] - to provide system ADM authority
[SYSCTRL[, ]] - to provide system control authority
}
TO [AuthID][,...]
[PUBLIC][WITH GRANT OPTION]
3. GRANT .. System privileges
Grants the system level privileges using which the list of actions that can be performed by a particular
user is defined
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
18/41
ER/CORP/CRS/DB07/003
Version No: 2.018Copyright 2004,
Infosys Technologies Ltd
GRANT . TO .
Used to grant access to new users;
Permission can be granted for all DML commands;
Permission is granted on a database/table/view; Permission for further grant.
E.g: User1 is an owner of Customer table.
User1 wants User2 perform queries on it.
User1 issues following command:
GRANT SELECT
ON Customer to User2;
To allow insert permission,
User1 issues the command-
GRANT INSERT ON Customer to User2;
GRANT SELECT, INSERT ON Customer to User2;
GRANT INSERT ON Customer to User2, User3;
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
19/41
ER/CORP/CRS/DB07/003
Version No: 2.019Copyright 2004,
Infosys Technologies Ltd
Restricting Privileges
GRANT SELECT, UPDATE ON Customer to User2
GRANT UPDATE ( Comm) ON Customer to User2
GRANT UPDATE (CName,City) ON Customer to User2;
By explicitly saying what kind of queries can be performed on a table/view, we can restrict the kind of
changes that may be done to a table/view by a particular user.
We can even specify what columns of a table can be updated as shown in the slide
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
20/412
ER/CORP/CRS/DB07/003
Version No: 2.020Copyright 2004,
Infosys Technologies Ltd
ALL & PUBLIC arguments
GRANT ALL PRIVILEGES ON Customer to User2
GRANT ALL ON Cusomer to PUBLIC;
GRANT SELECT ON Customer to PUBLIC;
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
21/412
ER/CORP/CRS/DB07/003
Version No: 2.021Copyright 2004,
Infosys Technologies Ltd
Granting with GRANT option
GRANT SELECT ON Customer To User2 WITH GRANT OPTION
GRANT SELECT ON User1.Customer To User3;
GRANT SELECT ON User1.Customer To user3 WITH GRANTOPTION;
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
22/412
ER/CORP/CRS/DB07/003
Version No: 2.022Copyright 2004,
Infosys Technologies Ltd
Taking PRIVILIGES away
The syntax of REVOKE command is patterned after GRANT,
but with a reverse meaning.
REVOKE{[ALTER[, ]]
[DELETE[, ]]
[INDEX[, ]]
[INSERT[, ]]
[SELECT[, ]]
[UPDATE [(column-name[,...])][, ]]
| ALL [PRIVILEGES] }
ON [TABLE] {table-name[,...] | view-name [,...]}
FROM AuthID[,...][PUBLIC [AT ALL LOCATIONS]]
[BY {AuthID[,...] | ALL}]
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
23/412
ER/CORP/CRS/DB07/003
Version No: 2.023Copyright 2004,
Infosys Technologies Ltd
Examples of REVOKE
REVOKE INSERT
ON Customer
FROM User2;
REVOKE SELECT, INSERT
ON Customer
FROM User2, User3;
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
24/412
Concurrency
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
25/412
ER/CORP/CRS/DB07/003
Version No: 2.025Copyright 2004,
Infosys Technologies Ltd
Concurrency
Two or more users access a database concurrently
DBMS ensures serializability
Problems associated with concurrent execution:
Lost update
Dirty read
Non repeatable read
Phantom records
Concurrency techniques:
Locking
Time stamping
Serializability:
If two transactions T1 and T2 are executing concurrently, the DBMS would ensure that the final result will be the same as when thesetransactions are executed serially (one after the other). This is called serializability of transactions.
The problems that may occur if this serializability is not ensured by the dbms are as given in the slide
Lost update:
This happens when one transaction updates a table and before it commits, another transaction reads the value (old value) and makes someupdates based on that. Consider the example below:
Let A=20
Read (A, a1) t1
a1 = a1 + 5 t2
t3 Read (A, b1)
Write(A,a1) t4
Commit t5
t6 b1= b1 * 2
t7Write(A,b1)
t8Commit
Here the update done by the first transaction is not taken into account at all.
Dirty read
A transaction A may read some data updated by another transaction B. B might not have yet committed. If B fails and gets aborted, the data asread by A would not exist (database would undo all changes done by B) and hence would be incorrect.
Nonrepeatable read
This happens when a transaction A reads a value from a table, another transaction B modifies that value and A gaian reads that value. Now Awill find a different value than what it was before.
Phantom records
Lets say a transaction A reads a set of rows from a table that satisfy a where condition. Now another transaction B inserts few more rows intothe table which would also satisfy the where condition. Now if A executes the query again, it will read more records than what it fetched before
These problems are illustrated in the following few slides with examples
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
26/412
Slide shows the serial execution of transactions T1 and T2. only after T1 finishes completely,
T2 begins.
ER/CORP/CRS/DB07/003
Version No: 2.026Copyright 2004,
Infosys Technologies Ltd
Read(A,a1)
a1=a1-50Write(A,a1)Read(B,b1)b1=b1+50Write(B,b1)
Read(A,a2)
temp=a2*0.1a2=a2-temp
Write(A,a2)read(B,b2)b2=b2+tempWrite(B,b2)
Trans T1Trans T1
Trans T2Trans T2
A = 200A = 200
B = 100B = 100
A = 150A = 150
A = 200A = 200
B = 100B = 100
B = 150B = 150
A = 150A = 150
A = 135A = 135B = 150B = 150
B = 165B = 165
A = 135A = 135
B = 165B = 165
t1
t2t3
t4
t5
t6t7
t8
TimeTime
Serial execution of two transactions
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
27/412
Serialized execution means, interleaving the execution of the two transactions T1 and T2 in
such a way that, the effect on the database is the same as executing these two transactionsserially.
ER/CORP/CRS/DB07/003
Version No: 2.027Copyright 2004,
Infosys Technologies Ltd
Trans T1Trans T1
Trans T2Trans T2Read(A,a1)a1=a1-50
Write(A,a1)Read(A,a2)temp=a2*0.1a2=a2-tempWrite(A,a2)
Read(B,b1)
b1=b1+50Write(B,b1)Commit Read(B,b2)
b2=b2+temp
Write(B,b2)commit
A = 150A = 150
A = 200A = 200
B = 100B = 100
B = 150B = 150
A = 150A = 150
A = 135A = 135
B = 150B = 150
B = 165B = 165
A = 135A = 135
B = 165B = 165A = 200A = 200
B = 100B = 100
t1
t2t3
t4t5
t6
t7
t8
Serialized execution
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
28/412
This example shows how two or more concurrent transactions which update a common
record can introduce inconsistency in the database
The Updation done by transaction T1 is totally lost even before it is seen
ER/CORP/CRS/DB07/003
Version No: 2.028Copyright 2004,
Infosys Technologies Ltd
Lost update A=100A=100
Read (A, a1) t1a1 = a1 + 50 t2
t3 Read (A, b1)write(A,a1) t4Commit t5
t6 b1 = b1 * 2t7 Write(A,b1)t8 Commit
A=100A=100A=100A=100
A=100A=100A=150A=150
A=200A=200A=200A=200
TimeTimeTrans T1Trans T1 Trans T2Trans T2
A=200A=200
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
29/412
This eg shows how two or more concurrent transactions that see uncommitted data of any
other transactions can introduce inconsistency in the db
Transaction T1 Updates record A at time t3 and then it decides to rollback or undo
But, Transaction T2 reads the updated data which is not the correct data, and does someUpdation on the wrong data and commits.
ER/CORP/CRS/DB07/003
Version No: 2.029Copyright 2004,
Infosys Technologies Ltd
Dirty Read
A=100A=100
Read(A,a1) t1
a1 = a1+50 t2Write(A,a1) t3
t4 Read(A,b1)t5 b1 = b1 * 2
Rollback t6t7 Write(A,b1)t8 Commit
A=100A=100
A=150A=150A=150A=150
A=100A=100A=300A=300
A=300A=300
TimeTimeTrans T1Trans T1 Trans T2Trans T2
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
30/413
This e.g. shows that in certain cases, interleaving of transactions some of which only retrieve
data and others update the data is being retrieved by the other transactions, may result ininconsistent data being generated.
Transaction T1 Updates record A and record B
Transaction T2 which has to calculate the sum of updated record, has read record A beforeUpdation and Record B after Updation, resulting in Incorrect Summary
or
The transaction T2 has seen the database in an inconsistent state and has thereforeperformed an INCONSISTENT ANALYSIS
ER/CORP/CRS/DB07/003
Version No: 2.030Copyright 2004,
Infosys Technologies Ltd
Read (A,a1) t1
a1 = a1-50 t2 Sum = 0t3 Read(A,b1)
Write(A,a1) t4t5 Sum = Sum + b1
Read(B,a2) t6a2 = a2 +50 t7Write(B,a2) t8
Commit t9t10 Read(B,b2)t11 Sum = Sum + b2t12 Commit
A = 100A = 100
B = 200B = 200TimeTimeTrans T1Trans T1 Trans T2Trans T2
A=100A=100
A=50A=50
B=200B=200
A=100A=100
Sum=100Sum=100
B=250B=250
Sum=350Sum=350
B=250B=250
Sum=350Sum=350
Incorrect summary
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
31/413
ER/CORP/CRS/DB07/003
Version No: 2.031Copyright 2004,
Infosys Technologies Ltd
TRANS-T1 Time TRANS-T2
Insert XT1 Sum = 0
Insert Y
T2
T3
Read (X, Bal_X)T4
Sum=sum + Bal_XT5
Read (Y, Bal_Y)T6
Sum=sum + Bal_Y
Insert Z
T7
COMMIT
COMMIT
T8
Phantom Record
T9
T10
Until TRANS-T1 COMMITS, the TRANS-T2 cannot see the existence of Z
Thus, Z is a PHANTOM RECORD as far as TRANS-B is concerned
Unless TRANS-T2, prevents TRANS-T1 from inserting Z, the two transactions are not serializable
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
32/413
ER/CORP/CRS/DB07/003
Version No: 2.032Copyright 2004,
Infosys Technologies Ltd
Locking
A lock is a variableassociated with each
data item in a
database.
When updated by a
transaction, DBMSlocks the data item
serializability could bemaintained by this.
Lock could be Shared
or Exclusive
An example ->
Granularity of locks
A database consists of several items that form a hierarchy. For example, the general hierarchy is:
1. A field
2. A data row or a tuple
3. A table
4. A tablespace
4. A databaseThe position of a database item in the hierarchy is an indication of its granularity. Thus, a field has a finer
granularity while a database has the coarsest granularity of all. Field level locking is not practicallybeing used because of the high overhead involved.
Shared lock is used by the DBMS when a transaction wants to read some data from the database. Anothertransaction can also acquire lock on the same data item and concurrently perform a read operation.
Exclusive lock is used when a transaction wants to update data. Once exclusive lock is acquired on a dataitem, another transaction cant lock the same data item (for read or write) until the first transaction releasesthe lock.
To summarize the compatibility:
S X
S Y N
X N N
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
33/413
ER/CORP/CRS/DB07/003
Version No: 2.033Copyright 2004,
Infosys Technologies Ltd
lock-S(B)Read(B,b1)
unlock(B)lock-S(A)
Read(A,a2)unlock(A)lock-X(B)Read(B,b2)Temp=a2+b2Write (B,Temp)Unlock(B)
Lock-X(A)Read(A,a1)Temp=a1+b1Write(A,Temp)
unlock(A)
Locking (Example)
T1T1 T2T2B=200B=200
A=100A=100
A=300A=300
A=100A=100
B=200B=200
B=300B=300
A = 100A = 100
B = 200B = 200A = 300A = 300
B = 300B = 300
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
34/413
ER/CORP/CRS/DB07/003
Version No: 2.034Copyright 2004,
Infosys Technologies Ltd
Intent Locking
Also called Preemptive lock
Used to tag (lock) all ancestors of a node to be locked in share or exclusivemode.
This tag signals to other requesting transactions that locking may take place ata finer level by the transaction that holds the intent lock
This prevents other transactions from obtaining shared or exclusive lock to theancestors.
A variant of this is the SIX (Share-intention exclusive ) lock
Intent locking:
The lockable units in a generalized DBMS are:Database, Tablespace, Tables, Rows and Fields.
Each node of this list can be locked. When a lock request is granted to a node at a particular level, therequester node as well as all its descendants would be implicitly granted the same level of lock. For example, ifa transaction locks a table in exclusive mode, it means it has been implicitly given exclusive access to every rowof this table.
Thus, generalization can be made that the same lock is granted to the entire sub-tree starting at the requestednode.
Now, let us say transaction A wants to update some rows of a table, and doesnt know how many apriori.
If A locks only the row which it currently updates, then in the meantime, some other transaction B may acquirean exclusive lock on the entire table. After this, when A wants to update few more rows, it may not be possiblebecause the exclusive lock that has been acquired on the entire table by B will lock all rows of the table also inexclusive mode. A may have to wait till B releases the lock.
To avoid this, A can put an intention lock on the table (which means A has the intention to lock some nodesunder the subtree ie some rows of the table in future) . This will prevent B from acquiring an exclusive lock onthe table.
After this, A can acquire individual locks on each row it may want to read or update and complete the task.
The intention lock is of two types: intention share (IS) and intention exclusive (IX).
When a transaction A puts an IS lock on a table, it means A has the intention to lock some node under thissubtree, ie some row under the table in shared mode. This does not stop another transaction B from acquiring asimilar lock on the table. After this lock is aqcuired, if A wants to read any row of the table, it has to explicitly
acquire a shared lock on the row.A similar principle applies for the IX mode also.
The difficulty with this scheme is that, after acquiring an intention lock on a top level node (say a table), for evenreading any row of the table, the transaction has to acquire, individual shared lock on each such row.
Please refer to notes page of the next slide for explanation on the SIX lock
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
35/413
ER/CORP/CRS/DB07/003
Version No: 2.035Copyright 2004,
Infosys Technologies Ltd
Lock Compatibility matrix
S Gives share access to the requested node and to all descendants of the requested node. Any othertransaction can get a S lock or IS lock
only.
X Gives exclusive access to the requested node and to all its descendants. No otherlocks are permitted in this mode.
IS Gives intention share access to the requested node and allows the requester toexplicitly lock the descendants of this node in S , IS, IX
or SIX mode. Such explicit locking at granular level is possible only if compatibility at that finerlevel is supported.
IX Gives intention exclusive access to the requested node and allows the requesterto explicitly lock the descendants in IS or IX modes. This is again subject to compatibility with theother mode at the descendant's level.
SIX The subtree rooted by the node under consideration is locked explicitly in a sharedmode and a few nodes at lower levels are being locked in the exclusive mode. Only another IS lock isallowed in this mode.
To understand the SIX mode, consider, there is an employee table which transaction T1 would beupdating. As of now, it is not known as to which all rows may be required. If T1 locks the table in the
IX mode, then some other transaction may acquire an IX lock on the same node and lock anydescendant in the x mode. If T1 now comes to know that it has to update the same node that someother transaction has locked, it may have to wait. So, when T1 knows that it would be reading all therecords of the table and updating some records, it can obtain a shared and intention-exclusive (SIX)lock on the table (root) so that, no other transaction can lock any child node of this table (row) in anexclusive (X) mode
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
36/413
ER/CORP/CRS/DB07/003
Version No: 2.036Copyright 2004,
Infosys Technologies Ltd
Two-Phase locking
Serializability of concurrently executing transactions can be guaranteed by twophase locking
Each transaction is divided into two phases:
Growingphase locks can be acquired but not released
Shrinkingphase locks can be released but not acquired
The Lost update problem and the Dirty Read problem show that serializability requires that atransaction updating a record should not only lock the record but also hold the lock untilCOMMIT/ROLLBACK time. The Incorrect summary problem and the Phantom Recordproblem require that the table itself be locked even for read transaction until the transactioncomes to an end. Thus, we can see that locks keep growing during a certain phase of thetransaction and the locks start shrinking during the COMMIT/ROLLBACK time.
Thus, there is a lock-growing phaseand lock-shrinking phase. Such a scheme is called Two-phaselocking (2PL).
The 2PL theory can be summarized as:
A transaction should not operate on any object unless the transaction has acquired an appropriatelock on the object.
The transaction should not acquire any fresh locks after releasing a lock.
We can say: Ifa transaction follows the 2PL protocol, then it is serializable.
It is very important to notice that all 2PL transactions are serializable. But, not all serializabletransactions follow 2PL protocol.Thus, 2PL protocol is a sufficient but not necessary condition forserialization. 2PL is a way of ensuring serializability in a simple way.
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
37/413
ER/CORP/CRS/DB07/003
Version No: 2.037Copyright 2004,
Infosys Technologies Ltd
Lock-S(B)Read(B,b1)Lock-X(A)
unlock(B)
Lock-X(B)Read(B,b2)
Read(A,a1)Temp=a1+b1Write(A,Temp)unlock(A)
Locking (Example)T1T1
T2T2
B=200B=200
A=100A=100
A=300A=300
B=200B=200
A=300A=300
B=500B=500
Lock-S(A)Read(A,a2)unlock(A)
Temp=a2+b2
Write (B,Temp)Unlock(B)
A = 100A = 100
B = 200B = 200A = 300A = 300
B = 500B = 500
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
38/413
ER/CORP/CRS/DB07/003
Version No: 2.038Copyright 2004,
Infosys Technologies Ltd
Deadlock
Occurs when two or more separate processes compete for resources held byone another.
T1
Write_lock A
action(s)
Write_lock B
WAIT
T2 must wait for T1 to release lock
T1 must wait for
T2 to release lock
T2
Read_lock B
action(s)
Read_lock A
WAIT
Deadlock occurs when one transaction is waiting on another to release a lock it needs, and vice
versa - each then will wait forever for the other
If a deadlock occurs one of the offending transactions must be rolled backto allow the other toproceed
There are various methods for choosing which transaction to roll back when a deadlock is detected
Time (how long the transactions have been running)Data updated
Data remaining to update
There are schemes for preventing deadlock. But, most DBMSs allow them to occur and resolvewhen they are detected
Detection may be based on:
Timeout
Wait-for-graph (shows which transactions are waiting on which other transactionsfor a lock)
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
39/413
ER/CORP/CRS/DB07/003
Version No: 2.039Copyright 2004,
Infosys Technologies Ltd
Lock-X(A) t1update A t2
t3 lock-X(B)t4 update B
lock-X(B) t5update B t4 lock-X(A)
t5 update A
Deadlock
T1T1
T2T2
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
40/414
ER/CORP/CRS/DB07/003
Version No: 2.040Copyright 2004,
Infosys Technologies Ltd
Summary
Transaction is a logical unit of work which takes the database from oneconsistent state to the other
Atomicity, consistency, isolation and durability are the ACID properties of atransaction
Data integrity and Security are enforced using SQL DDL statements
Transactions should be able to concurrently execute without affecting theconsistency of the database
Locking is a mechanism of achieving such controlled concurrency
8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency
41/41
ER/CORP/CRS/DB07/003
Version No: 2.041Copyright 2004,
Infosys Technologies Ltd
Thank You!