This action might not be possible to undo. Are you sure you want to continue?
Page 1 of 8
TI':UlsnctioD - A transaction is a unit of program execution that accesses and possibly updates various data items. Usually. a transaction is initiated by a user program written in a high-level data manipulation language or programming language (for example. SQL. COBOL. C. C++. or Java). where it is delimited by statements (or function calls) of the form begin transaction and end transaction. The transaction consists of all operations executed between the begin transaction and end transaction. To ensure integrity of the data. we require that the database system maintain the following properties of the transactions: • Atomicirv - Either all operations of the transaction are reflected property in the database, or none are. COllsistl'DCV - Execution of a transaction in isolation (that is. with no other transaction executing concurrently) preserves the consistency of the database. Isolation - Even though multiple that. for every pair of transactions T, started, or Tj started execution transactio. ns executin. g concurrent transactions may execute concurrently. the system guarantees T, and Tj it appears to T that either Tj finished execution before after T, finished, Thus, each transaction is unaware of other 1Yl.lll· th e system.
DUl'nbilitv - After a transaction completes successfully. persist. even if there are system failures.
the changes it has made to the database
Transaction access data using two operations: • read(X). which transfers the data item X from the database to a local buffer belonging to the transaction that executed the read operation. • write(X). which transfers the <lata item X from the local buffer of the transaction that executed the write back to the database. For e.g .. consider a simplified banking system consisting of several accounts and a set of transactions that access and update those accounts. Let-T, be a transaction that transfers $50 from account A to account B. This transaction carl be cltfined as Ti: l'ead(A): A:=A-50: write(A): read(B); B:=B+50: write(B).
Let us now consider the ACID requirements.
Consisteucy • The consistency requirement here is that is that the SUlU of A and B be unchanged by the execution of the transaction, • Without the consistency requirement, money could be created or destroyed by the transaction. It can be verified easily that. if the database is consistent before an execution of the transaction. the database remains consistent after the execution of the transaction.
Amit Kr.Gupta B.E. 6th (I.T.) BIT,Durg
Page 2 of 8 of the application Amit Kr.T. 6th (I.Gupta B.Durg 1 .E.• Data Base Management System Ensuring consistency for an individual transaction is the responsibility programmer who codes the transaction.) BIT.
all the updates that it carried out on the database persist. just before the execution of transaction T. and.'l·ite(B) operation. i.. If a second concurrently running transaction reads A and B at this intermediate point and computes A+B. 6th (I. one after the other. • Ensuring the isolation property is the responsibility of a component of the database system called the concurrency . the values of accounts A and B reflected in the database are $950 and $2000.management component.. their operations may interleave in some undesirable way. Further. with the deducted total written to A and the increased total yet to be written to B. hardware failures or software enol's. it must be the case that no system failure will result in a loss of data corresponding to tills transfer of funds. if the transaction does not complete its execution. the database system restores the old values to make it appeal' as though the transaction never executed.. if several transactions are exec ired concurrently.e. • A way to avoid the problem of concurrently executing transactions is to execute transactions serially..2.control component. the values of accounts A and Bare $1000 and $2000. In this case. The updates carried out by the transaction have been written to disk before the transaction completes. • For e. . Information about the updates carried out by the transaction and written to disk is sufficient to enable t!le database tq reconstruct the updates when the database system is restarted after the failure. even if there is a system failure after the transaction completes execution. Isolation • Even if the consistency and atomicity properties are ensured for each transaction. it will observe an inconsistent value. but data written to disk are never lost. Now suppose that. Durability • Once the execution of the transaction completes successfully. Amit Kr. once II transaction completes successfully. • The basic idea behind ensuring atomicity is that the database system keeps track of the old values of any data on which a transaction performs a write.) BIT. suppose that the failure happened after the "v1'ite(A) operation but before the v. and the user who initiated the transaction has been notified that the transfer of-funds has taken place. the database is to/11porarily inconsistent while the transaction to transfer funds from A to B is executing.. These failures may be power failures. resulting in an inconsistent state.g .. 3. from completing its execution successfully. • \Ve assume for now that a failure of the computer system may ~sult illJoss of data in main memory. Atomicity • Suppose that. respectively.Gupta B.E. 4.Durg 2 .. • Ensuring atomicity is the responsibility of a component of the database system called the transaction .T. during the execution of transaction Ti. We can guarantee nrabiliry by ensuring that either 1.management component. • Ensuring durability is the responsibility of a component of the database system called the recovery . 2. • The isolation property of a rransacrion ensures that the concurrently execution of the transactions results in a system state that is equivalent to a state that could have been obtained had these transactions executed oue at a time in some order. • The durability property guarantees that. as we saw earlier. a failure occurs that prevents T. The system destroyed $50 as result of this failure.
ConCUI'l'ent Executions Transaction-processing systems usually allow multiple transactions to run concurrently. If the transactions are operating on different parts of the database. each starting only after the previou s one has completed. a schedule for a set of transactions must consist of all instructions of those transactions. The parallelism of the CPU and the I/O system can therefore be exploited to run multiple transactions in parallel. some short and some long.50: write(B). Allowing multiple transactions to update data concurrently causes several complications with consistency of the data. The database system must control the interaction among the concurrent transactions to prevent them from destroying the consistency of the database. the processor and disk spend less time idle. There may be a mix of transactions running on a system. Some involve I/O activity: others involve CPU activity.50: write(A): read(B): B :=B . 6th (I. sharing the CPU cycles and disk accesses amongjhem. A transaction consists of many steps. Ensuring consistency in spite of concurrent execution of transactions requires extra work: it is far easier to insist that transactions run serially-that is. in transaction TI. another transaction can be running in the CPU. Serial Schedule • • • Serial schedule consists of a sequence of instructions from various transactions. Correspondingly. While a read or write on behalf of one transaction is in progress on one disk. • Reduced waiting time. If transactions run serially. the instruction wr~te(A) must appear before the instruction read(B). the processor 8l1d disk utilization also increase: in other words. consider the transaction transfer of$50 from account A to B. or not performing any useful work. All of this increases the throughput of the system-that is. TI: read(A): A :=A . database consistency can be destroyed despite the correctness of each individual transaction. Serial schedules always preserve the consist.E. Therefore. the number of tra us actions executed in a given amount of time. I/O activity can be done in parallel with processing at the CPU. Concurrent execution reduces the unpredictable delays in funning transactions. For example. to unpredictable delays in running a transaction. in any valid schedule.) BIT. a short transaction ma~ have to wait for a preceding long transaction to complete. Thus. and must preserve the order ill -hich the instructions-appeal' in each individual transaction.Schedule represent the chronological order ill which instructions are executed in the system. Moreover. it is better to let them run concurrently. T J for performing For example. Schedule . while another disk may be executing a read or write on behalf of a third transaction. one at a time.ency of the database. Clearly.Durg 3 . However.T. it also reduces the aver-age response rime: the average time for a transaction to be completed after it has been submitted. for a set ofn transactions. there exist n! different valid serial schedules. It does so through a variety of mechanisms called concurrency-conrrol schemes. The CPU and the disks in a computer system call operate in parallel. where the instructions belonging to one single transaction appear together in that schedule. there are two good reasons for allowing concurrency: • Improved throughput and resource utilization. which can lead.Gupta B. Amit Kr. When several transactions run concurrently.
and transaction T] for perf o nning transfer of 10 percent of the balance from account A to B. since the various instructions from both transactions may now be interleaved. then perform a context switch. the number of possible schedules for a set of 11 transactions is much larger than II!.T1: read(A): A :=A .50: write(B). and so on.) BIT. If control of concurrent execution is left entirely to the operating system. including ones that leave the database in an inconsistent state are possible.Durg 4 . With multiple transactions. write(B). many possible schedules. 6th (I. SE'I'inl ScbE'dulE' I (Tl followed by T2) SE'l"inl ScbE'dulE' 2 (T2 followed by Tl) Tl read(A): A :=A .50: write(B). Now.te(B). rs. read(A): temp := A • 0. Thus.temp: "rrite(A): rend(B): B := B + temp. execute the second transaction for some time. If two transactions are running concurrently. it is not possible to predict exactly how many instructions of a transaction will be executed before the CPU switches to another transaction. Amit Kr. the CPU time is shared among all the transactions. T2 TI T2 read(A): temp :=A A := A - 0.50: write(A): read(B): B :=B. In general. read(A): A:=A-50: 'write(A): read(B): B :=B+ 50: write(B). It is the job of the database system to ensure that any schedule that gets executed will leave the database in a consistent state. the corresponding schedule no longer needs to be serial. Sometimes Concurrent schedules don't preserve the consistency of the database. and then switch back to the first transaction for some time.E.50: write(A): read(B): B :=B .T. we have two serial schedules for these transactions. The COUCUITE'OCy-cootl'olcomponent of the database system carries out this task.Gupta B.1: A := A .1: A := A .temp: \q. the operating system may execute one transaction for a little while.1: temp: 01< write(A): read(B): read(A): temp :=A '" 0. B := B .temp: write(A): read(B): B := B + temp: write (B). Several execution sequences are possible. COIlClllTgot 5chgdulE' (~ou-SUiill • 5clIE'(1ulE's) • • • When the database system executes several transactions concurrently.
E. 6th (I.T. Amit Kr.) BIT.For example. the concurrent schedules equivalent to above serial schedules are as follows.Durg 4 .Gupta B.
T.e. the schedule should.Gupta B.temp: write(B).1: A := A . read(A): A:=A-50: write(A): read(B): B := B .ite(A): * write(A): read(B): B :=B. St>l'inlizn bilitv • The objective of concurrency control component is to schedule or arrange the transactions in such a way as to avoid any interference. in some sense.temp. one transaction is committed before another is allowed to begin. Sertnliznbtliry is a concept that ensures the correctness of the instance of the database under concurrent execution of the transactions.1: A := A . We can ensure consistency of the database under concurrent execution by making sure that any schedule that executed has the same effect as a schedule that could have occurred without any concurrent execution.temp: wri te(A): * read(B): B :=B .. The concurrent schedule that doesn't preserve the consistency CODClllTelH Schedult> 3 TI read(A): A :=A .50: write(A): I Concurrent TI Scht>dllie 2 T2 read(A): temp :=A 0.temp: v-. 6th (I.50: write(B). The DBMS will have to find ways and device strategies to maximize concurrency in the system. "'nte(A): T2 * read(A): temp :=A 0. read(B): B := B + temp: write(B). We say that II non-serial schedule (concurrent schedule) is correct ifit produces the same results as Amit Kr. be equivalent to a serial schedule. where there are hundreds of users and thousands of transactions the serial execution of the transactions is not a viable option.ConCUlTenr Schedule TI read(A): A :=A .) BIT.50: write(B). read(B): B :=B+50: write(B). is as follows.50: T2 read(A): temp :=A 0..E. But in a multi-user environment. One obvious way of avoiding the interference of the transactions i50to execute them serially i. so that many transactions can execute in parallel without interfering with one another.Durg • • • 5 . read(B): B :=B+ temp: write(B).1: A := A . That is.
) BIT. Amit Kr. Such schedule is said to be serializable. 6th (I.some serial schedule.Durg 5 .E.Gupta B.T.
However. Thus. Sc11('<1ul(' 3 T l consider the following schedule 3 where only the read and write operations are shown: T 2 read(A) writet.E. and at least one of these instructions is a write operation. respectively (i. there are four cases that we need to consider: L 1 1 = read(Q). if Land Ij refer to the same data item Q. whose order does not matter. because the two instructions access different data items. If Ij comes before L. Ij = writet'Q). If there is no OdIeI 'write(Q) instruction after I. the order of Ii and I Jmatters. Since the write(A) instruction of Tz in schedule 3does not conflict with the read(B) instruction of TI. Let It and Ij be consecutive instructions of a schedule S. the write(A) instruction ofT2 does not conflict with the read(B) instruction of T'l . since the same value of Q is read by Ti and Tj . of transactions Tt and T] . • Swap the write(B) instruction of Ti with the write(A) instruction of Tz. \Ve expect S to be equivalent to S'. For example. then Tl does not read the value of Q that is written by Tj in instruction Ij. If L comes before Ij.Gupta B. 3. the order of these instructions does not affect either Tt or TJ. since all instructions appear in the same order in both schedules except for It and Ij. Since both instructions are write operations.T. Regardless of the initial system state. Ij = read(Q). 2.Conflict SeI'ializabilin' Let us consider a schedule S in which there are two consecutive instructions It and Ij. the writef. If Ii and Ij are instructions of different transactions and Ii and Ij do not conflict. Amit Kr. then 'we can swap the order of Land Ij to produce a new schedule S·.Durg 6 . Thus.A) read(A) write/A) read(B) write(B) read@) writefB) In this schedule. IfL and Ij refer to different data items. schedule 4. We say that Ii and IJconflict if they are operations by different transactions on the same data item. schedules 3 811d4 both produce the same final system state. Since we are dealing with only read and write instructions. Ij = writet'Q). Ii = write/Q). regardless of the order.) BIT. we can swap these instructions to generate an equivalent schedule. However. Ii = read(Q). then 'we can swap Land Ij 'without affecting the results of any instruction in the schedule. The order of Land Ij does not matter.c j). However. then the order of Ii and Ij directly affects the final value of Q in the database state that results fr0111 schedule S. 1 1 = write(Q). then Trreads the value ofQ that is written by Tj. 6th (I. We continue to swap non-conflicting instructions: • Swap the read(B) instruction of Tt with the read(A) instruction of Tz. 4. and IJ in S. Ij = read(Q). since the result of only the latter of the two write instructions is preserved in the database. then the order of the two steps may matter. only in the case where both Land 1 ) are read instructions does the relative order of their execution not matter. The order of Ii and Ij matters for reasons similar to those of the previous case. the value obtained by the next read(Q) instruction of S is affected.A instruction of TL.conflicts with the read(A) instruction of T2. • Swap the write(B) instruction of Ti with the read(A) instruction of Tz.
) BIT. l Write – Read (WR) conflict l Read – Write (RW) conflict l Write – Write (WW) conflict Ø Reading Uncommitted Data (WR Conflicts) Here.Durg 7 . Amit Kr. Such a read is called Dirty Read.T. 6th (I. a transaction T2 could overwrite the value of an object A. committed transactions could run against a consistent database and leave it in an inconsistent state. while T1 is still in progress. a transaction T2 could read a database object A that has been modified by another transaction T1. the problem is that we have a lost update. while T1 is still in progress. This situation could not arise in a serial execution of two transactions. Here.Gupta B. Ø Overwriting Uncommitted Data (WW Conflicts) Here. If T1 tries to read the value of A again. it will get a different result. which has not yet committed. This type of write is called a blind write. Exammple: T1 R(A) W(A) R(A) W(A) R(B) W(B) Commit T2 R(B) W(B) Commit Ø Unrepe atable Reads (RW Conflicts) Here. This type of read is called an Unrepeatable Read. which has already been modified by a transaction T1.E.Anomalies due to Interleaved Execution There are three main ways in which a schedule involving two consistency preserving. even though it has not modified A in the meantime. a transaction T2 could change the value of an object A that has been read by a transaction T1.
the transaction that performs the final write on A in S1 must also perform the final write on A in S2.) BIT. for whatever reason. * Any view serializable schedule that is not conflict variable contains a blind write. for each pair of transactions Ti and Tj such that Tj reads a data item previously written by Ti. For each data object A. Amit Kr. 3. If Ti reads the initial value of object A in S1.View Serializability Two schedules S1 and S2 over the same set of transactions. 2. A recoverable schedule is one where. In a system that allows concurrent execution. it must also read the value of A written by Tj in S2. * A schedule is view serializable if it is view equivalent to some serial schedule.Durg 8 . but the converse is not true. we need to undo the effect of this transaction to ensure the atomicity property of the transaction.Gupta B. Recoverability: If a transaction Ti fails. it is necessary also to ensure that any transaction Tj that is dependent on Ti (that is. it must also read the initial value of A in S2. * Every conflict serializable schedule is view serializable.T. 6th (I. are view equivalent if 1. we need to place restrictions on the type of schedules permitted in the system.E. the commit operation of Ti appears before the commit operation of Tj . To achieve this surety. Tj has read data written by Ti) is also aborted. If Ti reads a value of A written by Tj in S1.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.