transactions lect15

8/3/2019 Transactions Lect15

http://slidepdf.com/reader/full/transactions-lect15 1/21

DBMS-BTech-III1

Transactions

Lecture 15

Subject: DBMSPrepared by: Nirali Nanavati



DBMS-BTech-III2

Transactions

A collection of several operations on thedatabase that appears to be a single unitfrom the point of view of the db user.

Examples of transactions Written in high level DML or

programming languages like C++ orJava.

To ensure integrity of data followingproperties of transactions must bemaintained.



DBMS-BTech-III3

ACID

Atomicity. Either all operations of the transaction areproperly reflected in the database or none are.

Consistency. Execution of a transaction in isolationpreserves the consistency of the database.

Isolation. Although multiple transactions may executeconcurrently, each transaction must be unaware of otherconcurrently executing transactions. Intermediatetransaction results must be hidden from other concurrentlyexecuted transactions.

That is, for every pair of transactions T i and T j , itappears to T i that either T j , finished execution before T i started, or T j started execution after T i finished.

Durability. After a transaction completes successfully, thechanges it has made to the database persist, even if thereare system failures.



DBMS-BTech-III4

Transaction Concept

A transaction is a unit of programexecution that accesses and possiblyupdates various data items.

E.g. transaction to transfer Rs.5000from account A to account B:1.read(A)//transfers data from db to buffer

2.A := A –

50003.write(A)

4.read(B )

5.B := B + 5000

6.write(B)



DBMS-BTech-III5

Two main issues to deal with:

Failures of various kinds, such ashardware failures and system crashes

Concurrent execution of multipletransactions



DBMS-BTech-III6

Example of Fund Transfer

Transaction to transfer Rs.5000 fromaccount A to account B:1. read(A)

2. A := A –

50003. write(A)

4. read(B )

5. B := B + 5000

6. write(B) Atomicity requirement

if the transaction fails after step 3 and before step6, money will be “lost” leading to an inconsistent

database state. A + B not preserved.



DBMS-BTech-III7

Solution: the system should ensure thatupdates of a partially executedtransaction are not reflected in the

database.- Atomicity is also ensured by restoring

the old values in case of partialexecution

- Managed by Transaction managementcomponent.



DBMS-BTech-III8

Durability requirement

Once the user has been notified that thetransaction has completed (i.e., the

transfer of the Rs.5000 has taken place),the updates to the database by thetransaction must persist even if there aresoftware or hardware failures.



DBMS-BTech-III9

Solution: Update written to disk beforetransaction completes.

Info about updates must be enough to

reconstruct the updates. Ensured by recovery management

component



DBMS-BTech-III10

Consistency requirement In above example: the sum of A and B is unchanged by the

execution of the transaction

In general, consistency requirements include

• Explicitly specified integrity constraints such asprimary keys and foreign keys

• Implicit integrity constraints• e.g. sum of balances of all accounts, minus sum of

loan amounts must equal value of cash-in-hand

A transaction must see a consistent database.

During transaction execution the database may betemporarily inconsistent.

When the transaction completes successfully the databasemust be consistent

• Erroneous transaction logic can lead to inconsistency



DBMS-BTech-III11

Isolation requirement

If between steps 3 and 6, another transaction T2 isallowed to access the partially updated database, itwill see an inconsistent database (the sum A + B willbe less than it should be).

T1 T2

1. read(A)

2. A := A – 50

3. write(A)read(A), read(B),

print(A+B)4. read(B )

5. B := B + 50

6. write(B



DBMS-BTech-III12

Isolation can be ensured trivially byrunning transactions serially

that is, one after the other.

However, executing multiple transactionsconcurrently has significant benefits, aswe will see later.

Concurrency control component



DBMS-BTech-III13

Transaction States

Active – the initial state; the transaction stays inthis state while it is executing

Partially committed – after the final statementhas been executed.

Aborted – after the transaction has been rolledback and the database restored to its state prior tothe start of the transaction.

Committed – after successful completion. Toundo a commited transaction; we need to executea compensating transaction.(This is theresponsibility of the user.)



DBMS-BTech-III14

Terminated – if it has either commited oraborted.Assumption:no loss of data from disk

Failed – the transaction cannot proceed with its

normal execution. In that case it is rolledback/aborted state. Done by the recoveryscheme.

2 options:

restart the transaction

• can be done only if no internal logicalerror

kill the transaction



DBMS-BTech-III

15

Contd…



DBMS-BTech-III

16

We must be cautious when dealingwith observable external writes, such

as writes to a terminal or printer. Must be done after the transaction

has commited.

E.g dispensing cash – alternative is acompensating transaction



DBMS-BTech-III

17

Implementation of Atomicityand Durability The recovery-management component of a database

system implements the support for atomicity anddurability.

E.g. the shadow-database scheme:

Copy of the db called the shadow copy is made

all updates are made on a new copy of thedatabase

• db_pointer is made to point to the updated

copy after• all updated pages have been flushed to disk.

• Old copy is then deleted.



DBMS-BTech-III

18



DBMS-BTech-III

19

db_pointer always points to the current consistent copyof the database.

It handles transaction and system failure before dbpointer is written to disk.

In case transaction fails, old consistent copy pointedto by db_pointer can be used, and the new copycan be deleted.

In case of system failure, it will restart and see no

new changes.- Imp restriction: db-pointer is updated atomically. Wecan do this by storing atomic pointer at beginning of ablock.



DBMS-BTech-III

20

Example: Text editing session

The shadow-database scheme: Assumes that only one transaction is active at a

time.

Assumes disks do not fail

Useful for text editors(rename and deleteoperation - atomic),

• extremely inefficient for large databases(why?)

Does not handle concurrent transactions



DBMS-BTech-III

21

Thank You

transactions lect15

Documents