ACID
Transaction in DBMS
“Transaction is a set of operations which are all logically related.”
• An executing program (process) that includes one or more database access operations
– Read operations (database retrieval, such as SQL SELECT)
– Write operations (modify database, such as SQL INSERT, UPDATE, DELETE)
– Transaction: A logical unit of database processing
– Example: Bank balance transfer of $100 dollars from a checking account to a saving
account in a BANK database
Transaction in DBMS
• Transaction Processing Systems: Large multi-user database systems
supporting thousands of concurrent transactions (user processes) per
minute
• Two Modes of Concurrency
– Interleaved processing: concurrent execution of processes is interleaved
in a single CPU
– Parallel processing: processes are concurrently executed in multiple
CPUs
– Basic transaction processing theory assumes interleaved concurrency
Transaction in DBMS
•Basic operations on an item X:
– read_item(X): Reads a database item named X into a program variable. To
simplify our notation, we assume that the program variable is also named X.
– write_item(X): Writes the value of program variable X into the database item
named X.
Transaction in DBMS
Recovery manager keeps track of the following operations (cont.):
•commit_transaction: Signals successful end of transaction; any changes (writes)
executed by transaction can be safely committed to the database and will not be undone.
•abort_transaction (or rollback): Signals transaction has ended unsuccessfully; any
changes or effects that the transaction may have applied to the database must be undone.
Concurrency Control: Lost Update Problems (W - W Conflict)
Tim Transaction-1 Transaction-2
e
t1 READ[X] The problem occurs when two different database
t2 X= X-40 transactions perform the read/write operations on the
t3 READ[X] same database items in an interleaved manner (i.e.,
t4 X= X+200 concurrent execution) that makes the values of the
t5 items incorrect hence making the database
t6 WRITE[X] inconsistent.
t7 WRITE[X]
•At time t1, Transaction-1 reads the value of account X, i.e., $500 (only read).
•At time t2, Transaction-1 deducts $40 from account X that becomes $460 (only deducted and not updated/write).
•Alternately, at time t3, Transaction-2 reads the value of account X that will be $500 only because Transaction-1 didn't
update the value yet.
•At time t4, Transaction-2 adds $200 to account X that becomes $700 (only added but not updated/write).
•At time t6, Transaction-1 writes the value of account X that will be updated as $460 only, as Transaction-2 didn't
update the value yet.
•Similarly, at time t7, Transaction-2 writes the values of account X, so it will write as done at time t4 that will be $700.
It means the value written by Transaction-1 is lost, i.e., $460 is lost.
Concurrency Control: Dirty Problems
Tim Transaction-1 Transaction-2
e
t1 READ[X] The problem occurs when two different database
t2 X= X+100 transactions perform the read/write operations on the
t3 WRITE[X] same database items in an interleaved manner (i.e.,
t4 READ[X] concurrent execution) that makes the values of the
t5 Rollback items incorrect hence making the database
{Server Down} inconsistent.
•At time t1, Transaction-1 reads the value of account X, i.e., $500 (only read).
•At time t2, Transaction-1 adds $100 from account X that becomes $600 (only deducted and not updated/write).
•At time t3, Transaction-1 writes the updated value in account X, i.e., $600.
• Then at time t4, transaction Transaction-2 reads account X that will be read as $600.
• Then at time t5, transaction Transaction-1 rollbacks due to server problem, and the value changes back to $600 (as
initially).
• But the value for account X remains $600 for transaction Transaction-2 as committed, which is the dirty read and
therefore known as the Dirty Read Problem
Transaction in DBMS
Recovery manager keeps track of the following operations (cont.):
•commit_transaction: Signals successful end of transaction; any changes (writes)
executed by transaction can be safely committed to the database and will not be undone.
•abort_transaction (or rollback): Signals transaction has ended unsuccessfully; any
changes or effects that the transaction may have applied to the database must be undone.
Desirable Properties of Transactions
Atomicity
•By this, we mean that either the entire transaction takes place at once or doesn’t happen at all.
•There is no midway i.e. transactions do not occur partially.
•Each transaction is considered as one unit and either runs to completion or is not executed at
all.
•It involves the following two operations.
• —Abort: If a transaction aborts, changes made to database are not visible.
• —Commit: If a transaction commits, changes made are visible.
•Atomicity is also known as the ‘All or nothing rule’.
Desirable Properties of Transactions
Consistency
•This means that integrity constraints must be maintained so that the database is consistent
before and after the transaction.
•It refers to the correctness of a database.
•The total amount before and after the transaction must be maintained.
• Total before T occurs = 500 + 200 = 700.
• Total after T occurs = 400 + 300 = 700.
Desirable Properties of Transactions
Isolation
•This property ensures that multiple transactions can occur concurrently without leading to
the inconsistency of database state.
•Transactions occur independently without interference.
•Changes occurring in a particular transaction will not be visible to any other transaction
until that particular change in that transaction is written to memory or has been committed.
•This property ensures that the execution of transactions concurrently will result in a state
that is equivalent to a state achieved these were executed serially in some order.
Desirable Properties of Transactions
Durability:
•This property ensures that once the transaction has completed execution, the updates and
modifications to the database are stored in and written to disk and they persist even if a
system failure occurs.
•These updates now become permanent and are stored in non-volatile memory.
•The effects of the transaction, thus, are never lost.
