DBMS-chap 2-Concurrency Control

1

DBMS Unit 1 - Chapter 2
Concurrency Control
1. What is a transaction? In what ways is it different from an ordinary program (such as a C program)?

A transaction is an execution of a user program, and is seen by the DBMS as a series or list of actions. The
actions that can be executed by a transaction include reads and writes of database objects, whereas actions in
an ordinary program could involve user input, access to network devices, user interface drawing, etc. In
database terms, a transaction is any action that reads from and/or writes to a database. A transaction may
consist of a simple SELECT statement to generate a list of table contents; it may consist of a series of related
UPDATE statements to change the values of attributes in various tables; it may consist of a series of INSERT
statements to add rows to one or more tables, or it may consist of a combination of SELECT, UPDATE, and
INSERT statements. We can define a transaction as - a logical unit of work that takes the database from one
consistent state to another.

During actual transaction execution (within the transaction’s physical time limit), the database may be
inconsistent. But when a transaction is committed, the database becomes consistent.

2. Define these terms: atomicity, consistency, isolation, durability, schedule, blind write, dirty read,
unrepeatable read, serializable schedule, recoverable schedule, avoids-cascading-aborts schedule.

(a) Atomicity means a transaction executes when all actions of the transaction are completed fully, or none
are. This means there are no partial transactions (such as when half the actions complete and the other half
do not).
(b) Consistency involves beginning a transaction with a ’consistent’ database, and finishing with a
‘consistent’ database. For example, in a bank database, money should never be ”created” or “deleted”
without an appropriate deposit or withdrawal. Every transaction should see a consistent database.
(c) Isolation ensures that a transaction can run independently, without considering any side effects that other
concurrently running transactions might have. When a database interleaves transaction actions for
performance reasons, the database protects each transaction from the effects of other transactions.
(d) Durability defines the persistence of committed data: once a transaction commits, the data should persist
in the database even if the system crashes before the data is written to non-volatile storage.
(e) A schedule is a series of (possibly overlapping) transactions.
(f) A blind write is when a transaction writes to an object without ever reading the object.
(g) A dirty read occurs when a transaction reads a database object that has been modified by another not-yet-
committed transaction.
(h) An unrepeatable read occurs when a transaction is unable to read the same object value more than once,
even though the transaction has not modified the value. Suppose a transaction T2 changes the value of an
object A that has been read by a transaction T1 while T1 is still in progress. If T1 tries to read the value of
A again, it will get a different result, even though it has not modified A.
(i) A serializable schedule over a set S of transactions is a schedule whose effect on any consistent database
instance is identical to that of some complete serial schedule over the set of committed transactions in S.
(j) A recoverable schedule is one in which a transaction can commit only after all other transactions whose
changes it has read have committed.
(k) A schedule that avoids-cascading-aborts is one in which transactions only read the changes of committed
transactions. Such a schedule is not only recoverable, aborting a transaction can be accomplished without
cascading the abort to other transactions.

3. List the ACID properties. Explain the usefulness of each.

The ACID properties, and the need for each of them are:

Atomicity: Either all operations of the transaction are reflected properly in the database, or none are. Lack of
atomicity will lead to inconsistency in the database.

mukeshtekwani@hotmail.com Prof. Mukesh N. Tekwani

2 DBMS-Unit 1- Chap 2 - Concurrency Control

Consistency: Execution of a transaction in isolation (that is, with no other transaction executing concurrently)
preserves the consistency of the database. This is typically the responsibility of the application programmer
who codes the transactions.

Isolation: When multiple transactions execute concurrently, for every pair of transactions Ti and Tj, it appears
to Ti that either Tj finished execution before Ti started, or Tj started execution after Ti finished. Thus, each
transaction is unaware of other transactions executing concurrently with it. The user view of a transaction
system requires the isolation property, and the property that concurrent schedules take the system from one
consistent state to another. These requirements are satisfied by ensuring that only serializable schedules of
individually consistency preserving transactions are allowed.

Durability: After a transaction completes successfully, the changes it has made to the database persist, even if
there are system failures.

4. Explain the terms consistency and isolation.

If there is no concurrent execution of other transactions, each transaction must preserve the consistency of the
database. DBMS assumes that consistency holds for each transaction. Users are responsible for ensuring
transaction consistency. The user must ensure that when a transaction is allowed to run to completion by itself
against a consistent database, the transaction will leave the database in a consistent state.
The isolation property is ensured by guaranteeing that even though actions of several transactions may be
interleaved, the net effect is identical to executing all transactions one after the other in serial order. E.g., if
two transactions T1 and T2 are executed concurrently, the net effect is guaranteed to be the same as executing
T1 and then T2 or T2 and then T1.

Database consistency is the property that every transaction sees a consistent database instance. Database
consistency follows from transaction atomicity, isolation and transaction consistency.

Consider the following example of transfer of Rs 1000 from Account A to Account B:

1. Read (A) ‘read balance of account A
2. A:= A – 1000 ‘debit Rs 1000 from A’s account –assume sufficient balance exists in A’s account
3. Write (A) ‘update A’s account with new balance
4. Read(B) ‘read B’s account balance
5. B := B + 1000 ‘update B’s account
6. Write (B)

Consistency requirement: The individual values of accounts A and B are changed by the execution of the
transaction only if it is totally successful.

Atomicity Requirement: If the transaction fails after step 3 and before step 6, the system should ensure that
the updates are not reflected in the database, otherwise database inconsistency will result.

Durability Requirement: Once the user has been notified that the transaction has been completed (i.e. the
transfer of Rs 1000/- has taken place), the updates to the database by the transaction must persist despite
failures of any kind.

Isolation Requirement: If between steps 3 and 6, another transaction is allowed to access the partially
updated database, it will see an inconsistent database (the sum of A and B will be different from what it should
be).

Prof. Mukesh N Tekwani mukeshtekwani@hotmail.com

DBMS-Unit 1- Chap 2 - Concurrency Control 3

5. Explain the terms atomicity and durability.
The recovery manager is a component of the DBMS that ensures atomicity and durability.
Transactions can be incomplete for three different reasons:

1. A transaction can be aborted, or terminated unsuccessfully, by the DBMS because some anomaly arises
during execution. If a transaction is aborted by the DBMS, it is automatically restarted and executed from
the beginning.
2. The system may crash (e.g., due to power failure) while one or more transactions are in progress
progress.
3. A transaction may encounter an unexpected situation (e.g., unable to access a disk or read an unexpected
value); in this case, the transaction terminates itself.

Thus, partial transactions can leave a database in an inconsistent state. So, a DBMS must find ways of
removing the effects of partial transactions. That is, each transaction must be atomic in nature – either all the
actions of the transaction are carried out or none. So how does a DBMS ensure atomicity of a transaction? A
DBMS ensures atomicity of a transaction by undoing the actions of an incomplete transaction. This is done by
the DBMS by maintaining a log of all writes to the database. This log is used to ensure durability. If the
system crashes before changes made by a completed transaction are written to the disk, the log is used to
remember and restore these changes when the system crashes.

6. What are transaction states / transaction state diagram / life cycle of a transaction? OR
During its execution, a transaction passes through several states, until it finally commits or aborts. List
all possible sequences of states through which a transaction may pass. Explain why each state transition
may occur.

The transaction states or life cycle of a transaction can be illustrated by the following diagram:

States of a Transaction

Active State: This is the state of any transaction while it executes.
Partially Committed: This is the state a transaction reaches after the last SQL statement of the transaction
has been executed. The changes have been updated in the memory but not written to the disk.
Failed: This is the state a transaction reaches after the RDBMS engine discovers that the normal execution of
a transaction can no longer proceed.
Aborted: If a transaction is rolled back then it reaches this state. The database is restored to its initial state (i.e.
the state before the start of the transaction). After a transaction is aborted, the DBMS can take one of these
actions: (1) restart the transaction or (2) Kill the transaction
Committed: When a transaction is successfully completed and all changes have been written to the disk, it disk
reaches this state.

Thus the possible sequence of states are:
Active Partially committed Committed
Active Partially committed Aborted
Active Failed Aborted



7. Describe the terms transaction, schedule, complete schedule and serial schedule.

Transaction: A transaction is a series or list of actions. The actions that can be executed by the DBMS can be
read and write of database objects. According to convention, we say that, an object O is read into a variable
also denoted by O. So, the if a transaction T is performing the action of reading an object O, we denote it by
RT(O). Similarly, the action of writing the object O can be denoted by WT(O).

A transaction must also specify its final state – commit or abort. Thus CommitT means the transaction T is
committed (completed successfully) while AbortT means that the transaction ran into problems and had to be
aborted.

While discussing transactions, two assumptions are made:

1. Transactions interact with each other only through the database read and write operations; that is
transactions are not allowed to exchange messages.
2. A database is a fixed collection of independent objects.

Schedule:
A schedule is a list of actions (reading, writing, aborting or committing) from a set of transactions and the
order in which two actions of a transaction T appear in a schedule must be the same as the order in which they
appear in T. A schedule describes the actions of a transaction as seen by the DBMS. We can say that a
schedule represents an actual or a potential execution sequence. The following figure shows the execution
order (schedule) for two transactions T1 and T2.

T1 T2 A transaction can also carry out other actions such as reading/writing
R(A) operating system files, performing calculations, etc. But these actions do
W(A) not affect other transactions. Thus, the effect of one transaction on another
R(B) is only in terms of common database objects and the operations of read and
W(B) write on the database.
R(C )
W(C )

Complete Schedule and Serial Schedule:
In the above schedule, we have not shown an abort or commit action for the transactions. If a schedule
contains either the abort or commit for each transaction is called a complete schedule. A complete schedule
must contain all the actions for every transaction that appear in it. If the actions of different transactions are
executed from start to finish, one by one, then the schedule is called serial schedule.

8. Explain the distinction between the terms serial schedule and serializable schedule.

A schedule in which all the instructions belonging to one single transaction appear together is called a serial
schedule. A serializable schedule has a weaker restriction that it should be equivalent to some serial schedule.
There are two definitions of schedule equivalence – conflict equivalence and view equivalence.

9. What are concurrent transactions? Why does DBMS interleave concurrent transactions? OR What is
the motivation for concurrent transactions?
The word concurrent means happening at the same time. Concurrency is achieved by interleaving the
transactions in a system. Multiple transactions can be allowed to run concurrently in a system because it has
the following advantages:

1. Better utilization of processor and hard disk, and this leads to better transaction throughput. i.e., while one
transaction is using the CPU, the other transaction is performing read/write operations o n the disk.



2. The average response times for transactions reduces. A short transaction need not wait behind a long
transaction. In serial execution, a short transaction could get stuck behind a long transaction and this
could lead to unduly long delays in response times.

Consider two transactions
T1: BEGIN A = A + 100; B = B – 100; END
T2: BEGIN A = 1.06 * A; B = 1.06 * B; END

The first transaction (T1) is transferring Rs 100 from B’s account to A’s account. The second transaction (T2)
is crediting both accounts with a 6% interest payment.
There is no guarantee that T1 will execute before T2 or vice-versa, if both are submitted together. But the net
effect must be equivalent to these transactions running serially in some order.

Now consider the following interleaving schedule: This is ok because result is OK
T1: A = A + 100 B = B – 100
T2: A = A * 1.06 B = B * 1.06

But consider the following schedule:
T1: A = A + 100 B = B – 100
T2: A = A * 1.06 B = B * 1.06

The DBMS’s view of the second schedule is as follows:
T1: R(A), W(A) R(B), W(B)
T2: R(A), W(A) R(B), W(B)

10. What is a serializable schedule? OR What is serializability?
In DBMS the basic assumption is that each transaction preserves database consistency. Thus, the serial
execution of a set of transactions preserves database consistency. A concurrent schedule is serializable if it is
equivalent to a serial schedule.

Consider the following serializable schedule:
T1 T2 Even though the actions of T1 and T2 are interleaved, the result of this schedule
R(A) is equivalent to first running T1 and then runningT2. T1’s read and write of B is
W(A) not influenced by T2’s actions on A. This interleaved schedule can also be the
R(A) serial schedule T1; T2.
W(A)
R(B ) If the transactions are executed serially in different orders, they may produce
W(B ) different results. But it is presumed that those results are also acceptable. Thus,
R(B ) the transactions T1 and T2 can be interleaved in a different order as shown
W(B) below; this schedule is equivalent to the serial schedule T2;T1
Commit
Commit
T1 T2
R(A)
W(A)
R(A)
R(B)
W(B)
W(A)
R(B)
W(B)
Commit
Commit



11. What are the anomalies that can occur due to interleaved transactions?

Concurrent (interleaved) transactions have advantage of improving throughput, resource utilization and
reduced waiting time. But transactions must leave the database in a consistent state.

There are three ways in which a schedule involving two transactions could run against a consistent database
and leave it in an inconsistent state. Two actions on the on the same data object conflict if at least one of them
is a write. The three anomalous situations can be described as follows:

(i) Reading uncommitted data (WR conflict) (dirty read)
(ii) Unrepeatable reads (RW conflict)
(iii) Overwriting Uncommitted Data (WW conflict) (lost updates)

We now discuss each of these:

(i) Reading uncommitted data (WR conflict): A transaction T2 could read a database object A that
has been modified by another transaction T1, which has not yet been committed. Such a read is called
a dirty read. Consider the following schedule:

T1 T2
R(A)
W(A)
R(A)
W(A)
R(B)
W(B)
Commit
R(B)
W(B)
Commit

The problem with this schedule is as follows: The transaction T1 may write a value into A that makes
the database inconsistent. As long as T1 overwrites this value with a ‘correct’ value of A before
committing, no harm is done if T1 and T2 run in some serial order, because T2 will not see the
temporary inconsistency in the database. But interleaved execution can lead to an inconsistency as
shown above. The problem with this schedule is this: the value of A written by T1 is read by T2
before T1 has completed all its changes (commits).

(ii) Unrepeatable Reads (RW conflicts): A transaction T2 could change the value of an object A that
has been read by a transaction T1, while T1 is still in progress. This situation causes two problems.
First, if T1 tries to read the value of A again, it will get a different result, even though it has not
modified A in the meantime. This situation could not arise in a serial execution of two transactions; it
is called an unrepeatable read. Second, suppose that both T1 and T2 read the same value of A, say,
5, and then T1, which wants to increment A by 1, changes it to 6, and T2, which wants to decrement
A by 1, decrements the value that it read (i.e., 5) and changes A to 4. Running these transactions in
any serial order should leave A with a final value of 5; thus, the interleaved execution leads to an
inconsistent state. The underlying problem here is that although T2's change is not directly read by
T1, it invalidates T1's assumption about the value of A, which is the basis for some of T1's
subsequent actions.

(iii) Overwriting Uncommitted Data (WW conflict): The third source of anomalous behavior is that a
transaction T2 could overwrite the value of an object A, which has already been modified by a
transaction T1, while T1 is still in progress. Even if T2 does not read the value of A written by T1, a



potential problem exists as the following example illustrates. Suppose that Harry and Larry are two
employees, and their salaries must be kept equal. Transaction T1 sets their salaries to $1,000 and
transaction T2 sets their salaries to $2,000. If we execute these in the serial order T1 followed by T 2,
both receive the salary $2,000; the serial order T2 followed by T1 gives each the salary $1,000.
Either of these is acceptable from a consistency standpoint. Notice that neither transaction reads a
salary value before writing it; such a write is called a blind write, for obvious reasons.

Now, consider the following interleaving of the actions of T1 and T2: T1 sets Harry's salary to
$1,000, T2 sets Larry's salary to $2,000, T1 sets Larry's salary to $1,000, and finally T2 sets Harry's
salary to $2,000. The result is not identical to the result of either of the two possible serial executions,
and the interleaved schedule is therefore not serializable. It violates the desired consistency criterion
that the two salaries must be equal. The problem is that we have a lost update.

Summarizing this example:
Let T1 : set salary to 1000, and
Let T2: set salary to 2000

Case 1: Consider the sequence T1 , T2:
T1: set salary of Harry to 1000
T1: set salary of Larry to 1000
---------------- Both salaries at same value 2000

Case 2: Consider the sequence T2 , T1:
---------------- Both salaries at same value 1000

Case 3: Consider the interleaved sequence T1 , T2, T1, T2:
---------------- Both salaries are not the same and the result is not same as in case 1 or 2 above.
The consistency criteria is violated.

12. What is a lock-based protocol? Explain the term ‘lock-compatibility matrix’. What are the drawbacks
of lock-based protocols?

A lock is a mechanism to control concurrent access to an object in a database table.
Data items can be locked in one of the two modes:

• Shared (S) mode: The data item can only be read (i.e., it cannot be modified) by the transaction that
obtained the shared lock.
• Exclusive (X) mode: The data item can be read as well as written to by a transction that obtained the
exclusive lock.

These lock requests are made to the built-in Concurrency Control Manager (CCM) which is a part of every
DBMS engine. A transaction is allowed to proceed only after the CCM grants such requests.



Lock-Compatibility Matrix:

S X A transaction may be granted a lock on an object if the requested lock
S True False is compatible with locks already held on that item by other
X False False transactions. E.g., if an object is already under shared mode lock,
it can be granted another shared lock; in fact any number of transactions can hold shared locks on an object.
But if an object is under shared mode lock, it cannot be granted an exclusive-mode lock (or vice-versa) until
the exclusive lock is removed.

If a lock cannot be granted due to lock request incompatibility, the requesting transaction has to wait until all
incompatible locks held by other transactions have been released.

Drawbacks of Lock-based Protocols:
The two drawbacks of lock-based protocols are: (1) deadlock and (2) starvation.
Consider the following schedule:

T1 T2 Remarks
X(B) T1 gets exclusive lock on B for writing and writing
R(B) T1 reads B
B = B - 100 B modified by T1; allowed since T1 has exclusive lock on B
W(B) T1 writes B
S(A) T2 obtains shared lock on B. B is available to T1 also
R(A) T2 reads A
S(B) T2 ‘tries’ to obtain shared lock on B, but B is already under
exclusive lock by T1. This causes a problem!
X(A) T1 cannot exclusive lock of A because A is under shared lock of T2.

Neither transaction T1 not T2 can proceed because executing the lock S(B) causes T2 to wait for T1 to release
its lock on B, while executing X(A) causes T1 to wait for T2 to release its lock on A. Such a situation is called
a deadlock. A deadlock can be handled by rolling back either T1 or T2 and releasing their locks. Starvation
is also possible if concurrency control manager is badly designed.

13. What is a locking protocol? Describe the Strict Two-Phase Locking (Strict 2PL) protocol. What can you
say about the schedules allowed by this protocol?

A DBMS must be able to ensure that only serializable, recoverable schedules are allowed, and that no actions
of committed transactions are lost while undoing aborted transactions. A DBMS typically uses a locking
protocol to achieve this.

A locking protocol is a set of rules to be followed by each transaction (and enforced by the DBMS), in order
to ensure that even though actions of several transactions might be interleaved, the net effect is identical to
executing all transactions in some serial order.

Strict Two Phase Locking (Strict 2PL):
This protocol requires that each transaction issue lock and unlock requests in two phases:

1. Growing phase: A transaction may obtain locks, but may not release any locks.
2. Shrinking phase: A transaction may release locks but may not obtain any new locks.

The most widely used locking protocol, called Strict Two-Phase Locking, or Strict 2PL, has two rules. The
rules are:



(1) First rule in Strict 2PL (Acquire an appropriate lock): If a transaction T wants to read an object, it first
requests a shared lock on the object. If a transaction wants to modify an object, it must first request an
exclusive lock on the object. A transaction that has an exclusive lock can also read the object; an
additional shared lock is not required. A transaction that requests a lock cannot be executed till the DBMS
is able to grant it the requested lock. The DBMS keeps track of the locks it has granted and ensures that if
a transaction holds an exclusive lock on an object, no other transaction holds a shared or exclusive lock
on the same object.
(2) The second rule in Strict 2PL (Release the lock when no longer required): All locks held by a
transaction are released when the transaction is completed. Requests to acquire and release locks can be
automatically inserted into transactions by the DBMS; users need not worry about these details.

The locking protocol allows only `safe' interleavings of transactions. If two transactions access completely
independent parts of the database, they will be able to concurrently obtain the locks that they need and proceed
on their ways. But, if two transactions access the same object, and one of them wants to modify it, their
actions are ordered serially. The transaction that obtained the lock first will complete all its actions first before
this lock is released and the other transaction can proceed.

Consider the schedule shown below:

T1 T2 Remarks
R(A) Let A = 10, initially
W(A) T1 changes A to 20
R(A) T2 reads the value of A as 20
W(A)
R(B)
W(B)
Commit
R(B)
W(B)
Commit

This interleaving could result in a state that cannot result from any serial execution of the three transactions.
For instance, T1 could change A from 10 to 20, then T2 (which reads the value 20 for A) could change B from
100 to 200, and then T1 would read the value 200 for B. If run serially, either T1 or T2 would execute first,
and read the values 10 for A and 100 for B: we see that, the interleaved execution is not equivalent to either
serial execution.

If the Strict 2PL protocol is used, the above interleaving is disallowed. Let us see why. Assuming that the
transactions proceed at the same relative speed as before, T1 would obtain an exclusive lock on A (denoted by
X(A) in the figure below), first and then read and write A.

Then, T2 would request a lock on A. However, this request cannot be granted until T1 releases its exclusive
lock on A, and the DBMS therefore suspends T2. T1 now proceeds to obtain an exclusive lock on B, reads and
writes B, then finally commits, at which time its locks are released. T2's lock request is now granted, and it
proceeds.



In this example the locking protocol results in a serial execution of the two transactions. In general, however,
the actions of different transactions could be interleaved. As an example, consider the interleaving of two
transactions shown in figure below, which is permitted by the Strict 2PL protocol.

T1 T2 Remarks
S(A) Shared lock obtained as only reading is to be done by T1
R(A)
S(A) Shared lock obtained as only reading is to be done by T2
R(A)
X(B) Get exclusive lock on object B because it has to be written to by T2
W(B) T2 performs write operation on B
Commit
X(C ) T1 acquires exclusive lock on C because it has to be written to.
R(C )
W(C )
Commit

Thus, the strict 2PL allows only serializable schedules and the anomalies of dirty read, lost updates, etc do not
occur with this protocol.

14. Describe the terms ‘conflict serializability’ and ‘view serializability’

The basic assumption is that each transaction must preserve the database consistency; this is one of the main
properties (ACID).Thus, the serial execution of transactions must preserve database consistency. A concurrent
schedule is serializable if it is equivalent to a serial schedule.

Conflict serializability:
Consider instructions Ii and Ij of transactions Ti and Tj. These instructions conflict only if there is some object
Q accessed both by Ii and Ij and atleast one of those instructions wrote Q.

Consider the following situations:

Instruction Action Instruction Action Remarks
Ii Read (Q) Ij Read (Q) Ii and Ij donot conflict
Ii Read (Q) Ij Write (Q) Ii and Ij conflict
Ii Write(Q) Ij Read (Q) Ii and Ij conflict
Ii Write(Q) Ij Write (Q) Ii and Ij conflict

If Ii and Ij are consecutive in a schedule and they do not conflict, their results would remain the same even if
they had been interchanged in the schedule. Thus, if a schedule S can be transformed into a schedule Z by a
series of swaps of non-conflicting instructions, then S and Z are conflict equivalent. Schedule S is conflict
serializable if it is conflict equivalent to a serial schedule.
Here is an example of a schedule that is not conflict serializable:

T1 T2
Read (Q)
Write(Q)
Write(Q)

View Serializability:



Consider two schedules S1 and S2 where the same set of transactions are involved in both schedules. A
schedule is shown below:

T1 T2
Read (A)
A = A – 500
Write(A)
Read(B)
B = B - 10
Write (B)
Read(B)
B = B + 50
Write(B)
Read(A)
A = A + 10
Write(A)

The schedules S and S’ are said to be view equivalent if these three conditions are satisfied:

1. For each object Q, if transaction T1 reads the initial value of Q in schedule S1, then the transaction T1
must also read the initial value of Q in schedule S2.
2. For each data item Q, if transaction T1 executes Read(Q) in schedule S1and if that value was produced by
a write(Q) operation of transaction T2, then the transaction T1 in schedule S2 must also read the value of
Q that was produced by T2.
3. For each data item Q, the transaction that performs the final Write(Q) operation in schedule S1 must
perform the final write(Q) operation in schedule S2.

View equivalence is based purely on reads and writes alone. A schedule S is view serializable if it is
equivalent to a serial schedule. Every conflict serializable schedule is also a view serializable schedule. The
following schedule is view serializable:

T1 T2 T3
Read(Q)
Write(Q)
Write(Q)
Write(Q)

*****


DBMS-chap 2-Concurrency Control

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a DBMS-chap 2-Concurrency Control

Similar a DBMS-chap 2-Concurrency Control (20)

Más de Mukesh Tekwani

Más de Mukesh Tekwani (20)

Último

Último (20)

DBMS-chap 2-Concurrency Control