Docsity
Docsity
Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity

Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips
Guidelines and tips
Sell on Docsity
Sell on Docsity
Docsity AI
Docsity AI
Log inSign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search for your university

Find the specific documents for your university's exams

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents
download point icon20 Points

For each uploaded document

Answer questions
download point icon5 Points

For each given answer (max 1 per day)

All the ways to get free points
Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

Transaction Processing in Database Management Systems (DBMS) - Prof. Edwin, Lecture notes of Database Management Systems (DBMS)

Masinde Muliro University of Science and TechnologyDatabase Management Systems (DBMS)
Prof. Simiyu Edwin

A comprehensive overview of transaction processing in database management systems (dbms). It delves into the concept of transactions as logical units of processing, exploring their key notations, states, and management. The document emphasizes the acid properties (atomicity, consistency, isolation, and durability) that ensure data integrity and consistency in concurrent environments. It further examines different scheduling methods, including serial, non-serial, and serializable schedules, highlighting their impact on transaction execution and data consistency. The document concludes by analyzing various types of conflicts that can arise during concurrent transactions, such as write-read, read-write, and write-write conflicts, and their potential consequences for database integrity.

Typology: Lecture notes

2023/2024

Available from 12/16/2024

osage-newton
osage-newton 🇰🇪

3 documents

1 / 7

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
4 Transaction Processing
4.1 What is a transaction?
A transaction is a logical unit of processing in a DBMS which entails one or more database
access operations. All types of database access operations which are held between the begin
and end transaction statements are considered as a single logical transaction. During the
transaction the database is inconsistent. Once the transaction is committed the database state is
changed from one consistent state to another. In a nutshell, database transactions represent real-
world events of any enterprise.
These sets of instructions (statements) do several read and write operations on database. Thus,
transactions can be considered as the various read and write operations done by the user
programs on a database.
4.1.1 Key Notations in Transaction Management
The key notations in transaction management are as follows:
Object. The smallest data item which is read or updated by a transaction
Transaction: It is termed as the execution of query in DBMS. Transaction is represented
by the symbol T
Read Operation. Read operation on particular object is notated by symbol R (object-
name).
Write Operation. Write operation on particular object is notated by symbol W (object-
name).
Commit. This term used to denote the successful completion of one Transaction.
Abort. This term used to denote the unsuccessful or interrupted Transaction.
4.1.2 Transaction states
The various states of a Database Transaction are listed below
State
Transaction types
Active State A transaction enters into an active state when the execution process
begins.
During
this
read
or
write
operations
can
be
performed.
Partially
Committed
A transaction goes into the partially committed state after the end of a
transaction.
Committed State A transaction is in committed state, after it has already completed its
execution successfully. Moreover, all of its changes are recorded to the
database
permanently.
Failed State A transaction is in failed state when any one of the checks fails or if the
transaction
is
aborted
while
it
is
in
the
active
state.
Terminated State A transaction is in terminated state when certain transactions which are
leaving
the
system
can't
be
restarted.
pf3
pf4
pf5

Partial preview of the text

Download Transaction Processing in Database Management Systems (DBMS) - Prof. Edwin and more Lecture notes Database Management Systems (DBMS) in PDF only on Docsity!

4 Transaction Processing

4.1 What is a transaction? A transaction is a logical unit of processing in a DBMS which entails one or more database access operations. All types of database access operations which are held between the begin and end transaction statements are considered as a single logical transaction. During the transaction the database is inconsistent. Once the transaction is committed the database state is changed from one consistent state to another. In a nutshell, database transactions represent real- world events of any enterprise. These sets of instructions (statements) do several read and write operations on database. Thus, transactions can be considered as the various read and write operations done by the user programs on a database. 4.1.1 Key Notations in Transaction Management The key notations in transaction management are as follows:  Object. The smallest data item which is read or updated by a transaction  Transaction: It is termed as the execution of query in DBMS. Transaction is represented by the symbol T  Read Operation. Read operation on particular object is notated by symbol R (object- name).  Write Operation. Write operation on particular object is notated by symbol W (object- name).  Commit. This term used to denote the successful completion of one Transaction.  Abort. This term used to denote the unsuccessful or interrupted Transaction. 4.1.2 Transaction states The various states of a Database Transaction are listed below State Transaction types Active State A transaction enters into an active state when the execution process begins. During this state read or write operations can be performed. Partially Committed A transaction goes into the partially committed state after the end of a transaction. Committed State A transaction is in committed state, after it has already completed its execution successfully. Moreover, all of its changes are recorded to the database permanently. Failed State A transaction is in failed state when any one of the checks fails or if the transaction is aborted while it is in the active state. Terminated State A transaction is in terminated state when certain transactions which are leaving the system can't be restarted.

Figure 1.1 Transaction States in DBMS 4.1.3 Transaction Management A user program executed by DBMS may have several transactions. In the web environment, there is a possibility of several users accessing data that is stored in the same database. To improve the effective throughput of the DBMS, there is need for a mechanism to enable concurrent transactions. A Transaction Manager is responsible for scheduling the transactions and providing the safest path to complete available tasks. To maintain the data accuracy and consistency in consideration of concurrent access and system failures, the DBMS need to ensure that four important properties of a transaction are upheld. These properties are called as ACID properties. 4.1.4 ACID Properties of DBMS ACID is an acronym for Atomicity, Consistency, Isolation, and Durability. Atomicity Either all operations in a transaction are carried out or none are. The meaning is the transaction cannot be subdivided, and hence, it must be processed in its entirety or not at all. Users should not have to worry about the effect of incomplete transactions in case of any system crash occurs. Durability Durable means the changes are permanent. Once a transaction is committed, no subsequent failure of the database can reverse the effect of the transaction. If the system crashes before the changes made by a completed transaction are written to disk, then it should be remembered and restored during the system restart phase. If the transaction is interrupted in the middle way it leaves the database in the inconsistency state. These types of transactions are called as partial transactions. Partial transactions should be avoided in order to maintain consistency of a database. To reverse the actions done by the partial transactions, DBMS maintains certain log files. Each and every moment of disk writes

First schedule Second schedule 4.2.3 Serializable schedule A non-serial schedule is said to be serializable if its result is equal to the result of each individual transactions executed serially (one after the other). The serializability of schedules is used to find non-serial schedules that allow the transaction to execute concurrently without interfering with one another. It identifies the correctness of non- serial schedules. For example, the two non-serial schedules illustrated in section 4.2.2 are both non-serial; However, the first schedule is not serializable! The testing of serializability of a schedule is done using a serialization graph. 4.3 Interleaved Execution In order to achieve concurrency of transactions, operations of several transactions are inter- twinned in a serial manner and executed one by one according to a schedule. In such a schedule, the switching of execution from operations of one transaction to operations of another transaction is referred to as Interleaved Execution. In the above example, consider two transactions (T1, T2) involving two objects (A, B). Commit denotes successful completion of both transactions. First, one read and one write operation are done on the object A by Transaction T2. This is followed by T1 which performs one read operation on object A. The process goes on with object B and finally both Transactions are concluded successfully.

4.3.1 Anomalies due to Interleaved Transactions If all the transactions in DBMS systems are doing read operations on the database, then no problem will arise. When the read and write operations done alternatively there is a possibility of some type of anomalies. These are classified into three categories. a) Write–Read Conflicts (WR Conflicts) b) Read–Write Conflicts (RW Conflicts) c) Write–Write Conflicts (WW Conflicts) 4.3.2 WR Conflicts (Dirty Read) This happens when the Transaction T1 is trying to read object A which has been modified by another Transaction T2, but has not yet completed (committed). This type read is called as dirty read. Example; Consider two Transactions T1 and T2, each of which, when executed in isolation, preserves database consistency. T1 transfers $100 from A to B, and T2 increments both A and B by 6%. Explanation Suppose if the transactions are interleaved according to the above schedule then the account transfer program T1 deducts $100 from account A, then the interest deposit program T2 reads the current values of accounts A and B and adds 6% interest to each, and then the account transfer program credits $100 to account B. The outcome of this execution will be different from the normal execution whereby the two instructions are executed one by one. This type of anomalies leaves the database in inconsistency state.

Explanation If A and B are two accounts and their values have to be kept equal always, Transaction T updates both objects to 3,000 and T2 updates both objects to 2,000. At first T1 updates the value of object A to 3,000. Immediately T2 makes A as 2,000 and B as 2,000 and committed. After the completion of T2, T1 updates B to 3,000. Now the value of A is 2,000 and value of B is 3,000, they are not equal. Constraint violated in this case due to serial scheduling.