1

1. What is locking in database what are the types of locks?

Lock: In computer science, a lock is a synchronization mechanism for enforcing limits
on access to a resource in an environment where there are many threads of execution. Locks are one way of enforcing concurrency control policies. Generally, locks are advisory locks, where each thread cooperates by acquiring the lock before accessing the corresponding data. Some systems also implement mandatory locks, where attempting unauthorized access to a locked resource will force an exception in the entity attempting to make the access.

Database locks can be used as a means of ensuring transaction synchronicity. i.e. when making transaction processing concurrent (interleaving transactions), using 2-phased locks ensures that the concurrent execution of the transaction turns out equivalent to some serial ordering of the transaction. There are mechanisms employed to manage the actions of multiple concurrent users on a database - the purpose is to prevent lost updates and dirty reads. The two types of locking are Pessimistic and Optimistic Locking.

Pessimistic locking: A user who reads a record, with the intention of updating it, places an
exclusive lock on the record to prevent other users from manipulating it. This means no one else can manipulate that record until the user releases the lock. The downside is that users can be locked out for a very long time, thereby slowing the overall system response and causing frustration. o Where to use pessimistic locking: o This is mainly used in environments where data-contention (the degree of users request to the database system at any one time) is heavy; where the cost of protecting data through locks is less than the cost of rolling back transactions, if concurrency conflicts occur.

Optimistic locking: This allows multiple concurrent users access to the database whilst the system keeps a copy of the initial-read made by each user. When a user wants to update a record, the application determines whether another user has changed the record since it was last read. The application does this by comparing the initial-read held in memory to the database record to verify any changes made to the record. Any discrepancies between the initial-read and the database record violate concurrency rules and hence cause the system to disregard any update request. An error message is generated and the user is asked to start the update process again. It improves database performance by reducing the amount of locking required, thereby reducing the load on the database server. It works efficiently with tables that require limited updates since no users are locked out. However, some updates may fail. The downside is constant update failures due to high volumes of update requests from multiple concurrent users - it can be frustrating for users.

Where to use optimistic locking: This is appropriate in environments where there is low contention for data, or where read-only access to data is required. Optimistic concurrency is used extensively in .NET to address the needs of mobile and disconnected applications, where locking data rows for prolonged periods of time would be infeasible. Also, maintaining record locks requires a persistent connection to the database server, which is not possible in disconnected applications.

2.

Explain Two-phase locking

In databases and transaction processing two-phase locking, (2PL) is a concurrency control method that guarantees serializability. It is also the name of the resulting set of database transaction schedules (histories). The protocol utilizes locks that block (interpreted as signals to stop) other transactions from accessing the same data during a transaction's life. By the 2PL protocol locks are applied and removed in two phases: 1. Expanding phase: locks are acquired and no locks are released. 2. Shrinking phase: locks are released and no locks are acquired. Two types of locks are utilized by the basic protocol: Shared and Exclusive locks. Refinements of the basic protocol may utilize more lock types. Using locks that block processes, 2PL may be subject to deadlocks that result from the mutual blocking of two or Commitment ordering, which provides both serializability, and effective distributed serializability and global serializability, and 1. Strictness, which provides cascadelessness (ACA, cascade-less recoverability) and (independently) allows efficient database recovery from failure. Additionally SS2PL is easier, with less overhead to implement than both 2PL and S2PL, provides exactly same locking, but sometimes releases locks later. However, practically (though not simplistically theoretically) such later lock release occurs only slightly later, and this apparent disadvantage is insignificant and disappears next to the advantages of SS2PL. Thus, the importance of the general Two-phase locking (2PL) is historic only, while Strong strict two-phase locking (SS2PL) is practically the important mechanism and resulting schedule property.

Strict two-phase locking

The strict two-phase locking (S2PL) class of schedules is the intersection of the 2PL class with the class of schedules possessing the Strictness property.

To comply with the S2PL protocol a transaction needs to comply with 2PL, and release its write (exclusive) locks only after it has ended, i.e., being either committed or aborted. On the other hand, read (shared) locks are released regularly during phase 2. Implementing general S2PL requires explicit support of phase-1 end, separate from transaction end, and no such widely utilized product implementation is known.

Strong strict two-phase locking

To comply with strong strict two-phase locking (SS2PL) the locking protocol releases both write (exclusive) and read (shared) locks applied by a transaction only after the transaction has ended, i.e., only after both completing executing (being ready) and becoming either committed or aborted. This protocol also complies with the S2PL rules. A transaction obeying SS2PL can be viewed as having phase-1 that lasts the transaction's entire execution duration, and no phase-2 (or a degenerate phase-2). Thus, only one phase is actually left, and "two-phase" in the name seems to be still utilized due to the historical development of the concept from 2PL, and 2PL being a super-class. The SS2PL property of a schedule is also called Rigorousness. It is also the name of the class of schedules having this property, and an SS2PL schedule is also called a "rigorous schedule". The term "Rigorousness" is free of the unnecessary legacy of "twophase," as well as being independent of any (locking) mechanism (in principle other blocking mechanisms can be utilized). The property's respective locking mechanism is sometimes referred to as Rigorous 2PL. Many variants of SS2PL exist that utilize various lock types with various semantics in different situations, including cases of lock-type change during a transaction. Notable are variants that use multiple granularity locking Lock compatibility for SCO Lock type read-lock write-lock read-lock write-lock X X 3. What is concurrency control and what is its objective The coordination of the simultaneous execution of transaction in a multiuser database system is known as concurrency control. The objective of concurrency control is to ensure the serializability of transaction in a multiuser database environment. Concurrency control is important because the simultaneous execution of transactions over a shared database can create several data integrity and consistency problems. The three main problems are lost updates, uncommitted data and inconsistent retrievals. Lost Updates: This occurs when a set of transaction tries to update a single table and is executed before the one transaction is committed. For example: We have table Production and a attribute quantity and its value now is 35. Two transactions want to update the value. Transaction T1 wants to add a value of 100 and T2 wants to subtract a value of 30. If transaction is executed sequentially one after the other:

T e im

T n a tio ra s c n 1T 1 2T 1 3T 1 4T 2 5T 2 6T 2

S p te Ra Qa ed un Q a = 5+ 0 u n 3 10 W Qa rite u n Ra Qa ed un Q a =3 -3 u n 15 0 W Qa rite u n

S reV lu to a e 3 5 15 3 15 3 15 0

If Transaction T2 happens before commit of transaction T1. Then the sequence would be:
T e im T n a tion ra s c 1T 1 2T 2 3T 1 4T 2 5T 1 6T 2 S tep Ra Qa ed un Ra Qa ed un Q a = 5+ 0 u n 3 10 Q a = 5- 3 un 3 0 W Qa rite u n W Qa rite u n S reV lu to a e 3 5 3 5

15 3 5

Uncommitted Data: The situation of uncommitted data occurs when two transactions, T1 and T2 are executed concurrently and the first transaction T1 is rolled back after the second transaction T2 has already accessed the uncommitted data thus violating the isolation property of transactions. For example: Consider the same two transactions T1 and T2. If T1 is rolled back due to an error during the process. If T2 occurs after the rollback happens, then we would get the correct result.
T e im T n a tion ra s c 1T 1 2T 1 3T 1 4T 2 5T 2 6T 2 S tep Ra Qa ed un Q a = 5+ 0 u n 3 10 W Qa rite u n **R L B C ** OL A K Ra Qa ed un Q a = 5- 3 un 3 0 W Qa rite u n S toreV lu a e 3 5 15 3 3 5 5

If the transaction T2 begins before the T1 rollback is completed then the result would be:
T e im T n a tion ra s c 1T 1 2T 1 3T 1 4T 2 5T 2 6T 2 S tep R dQ a ea u n Q a = 5+ 0 u n 3 10 W Qa rite u n R dQ a ea u n Q a =3 -3 u n 15 0 **R L B C ** OL A K W Qa rite u n S toreV lu a e 3 5 15 3 15 3

15 0

Inconsistent Retrievals: Inconsistent retrievals occur when a transaction calculates some aggregate functions over a set of data while other transactions are updating the data. The problem is that the

transaction might read some data before they are changed and other data after they are changed, thereby yielding inconsistent results. 4. How concurrency control is done by using locking methods A lock guarantees exclusive use of a data item to a current transaction, i.e., Transaction T2 does not have access to a data item that is currently being use by transaction T1. A transaction acquires a lock prior to data access; the lock is released when the transaction is completed so that another transaction can lock the data item for its exclusive use. Most multiuser DBMSs automatically initiate and enforce locking procedures. All lock information is managed by a lock manager, which is responsible for assigning and policing the locks used by the transactions. In locking system there are different levels of locking like database, table, page, row and field level locks.

Database Level: In a database level lock, the entire database is locked, thus preventing the use of any tables in the database by transaction T2 while a transaction T1 is being executed. This level of locking is good for batch processes, but it is unsuitable for online multiuser DBMSs. Table Level: In a table level lock, the entire table is locked, preventing access to any row by transaction T2 while transaction T1 is using the table. If a transaction requires access to several tables, each table may be locked. However, two transactions can access the same database as long as they access different tables. Page Level: In a page level lock, the DBMS will lock an entire diskpage. A diskpage or page is nothing but a diskblock which has some fixed size such as 4K, 8K or 16K. A table can span several pages, and a page can contain several rows of one or more tables. Row Level: A row level lock is must less restrictive lock. The DBMS allows concurrent transaction to access different rows of the same table even when the rows are located on the same page. Field Level: The field level lock allows concurrent transactions to access the same row as long as they require the use of different fields within that row.

Lock Types: Regardless of the level of locking, the DBMS may use different lock types: binary or shared/exclusive. Binary Locks: A binary lock has only two states locked(1) and unlocked(0). If a object like database, table etc., is locked by a transaction, no other transaction can use that object. if an object is unlocked, any transaction can lock the object for its use. Every database operation requires that the affected object be locked and a transaction must unlock the object after its termination.

Shared/Exclusive Locks: An exclusive lock exists when access is reserved specifically for transaction that locked the object. The exclusive lock must be used when the potential for conflict exists. A shared lock exists when concurrent transactions are granted Read access on the basis of a common lock. A shared lock produces no conflict as long as all the concurrent transaction are read only. Read/Write lock usage some conflicts may raise like:
T 1 R d ea R d ea W rite W rite T 2 R d ea W rite R d ea W rite R s lt eu No C onflic t C onflic t C onflic t C onflic t

If transaction T2 updates data item X, an exclusive lock is required by T2 over data item X. the exclusive lock is granted if and only if no other locks are held on the data item. Therefore, if a shared or exclusive lock is already held on data item X by transaction T1, an exclusive lock cannot be granted to transaction T2 and T2 must wait to begin until T1 commits. This condition is known as the mutual exclusive rule. Only one transaction at a time can own an exclusive lock on the same object. Although locks prevent serious data inconsistencies, they can lead to two major problems:

The resulting transaction schedule may not be serializable The schedule may create deadlocks. A database deadlock, which is caused when two transactions wait for each other to unlock data.

5. How concurrency control is done with time stamping methods The time stamping approach to scheduling concurrent transactions assigns a global, unique time stamp to each transaction. The time stamp values produce an explicit order in which transactions are submitted to the DBMS. Time stamps must have two properties: uniqueness and monotonicity. Uniqueness ensures that no equal time stamp values can exist and monotonicity ensures that time stamp values always increase. All database operations (Read and Write) within the same transaction must have the same time stamp. The DBMS executes conflicting operations in the stamp order, thereby ensuring serialzability of the transaction. If two transactions conflict, one is stopped, rolled back, rescheduled, and assigned a new time stamp value. The disadvantage of the time stamping approach is that each value stored in the database requires two additional time stamp fields: one for the last time the field was read and one for the last update. Time stamping thus increases memory needs and the databases processing overhead. Time stamping tends to demand a lot of system resources because many transactions may have to be stopped, rescheduled and restamped. We have different types of time stamping schemes:

Wait/Die schemes Wound/Wait Schemes

This two schemes are used which transaction is rolled back and which continues executing. Consider two transaction with different time stamping T1 has a time stamp of 11548789 and T2 has a time stamp of 19562545. We can deduce from the time stamp that T1 is the older transaction and T2 is the newer transaction. Transaction Rquesting Transaction Owning Wait/Die Scheme Wound/Wait Scheme Lock Lock T1 (11548789) T2 (49562545) T1 waits until T2 is T1 rolls back T2 completed and T2 T2 is rescheduled releases its locks using the same time stamp T2(19562545) T1(11548789) T2 dies (rolls back) T2 waits until T1 is completed and T1 T2 is rescheduled releases its locks using the same time stamp The Wait/Die Scheme works like: If the transaction requesting the lock is the older of the two transactions, it will wait until the older transaction is completed and the locks are released If the transaction requesting the lock is the younger of the two transactions, it will die (roll back), it is rescheduled using the same time stamp In other words, in the wait/die scheme, the older transaction waits and the younger is rolled back and rescheduled. In the wound/wait scheme: If the transaction requesting the lock is the older of the two transactions, it will preempt (wound) the younger transaction (by rolling it back). T1 preempts T2 when T1 rolls back T2. The younger preempted transaction is rescheduled using the same time stamp. If the transaction requesting the lock is the younger of the transactions, it will wait until the other transaction is completed and the locks are released. In other words, the Wound/Wait Scheme, the older transaction rolls back the younger transaction and reschedules it. In both schemes, one of the transactions waits for the other transaction to finish and release the locks.