TRANSACTION

MANAGEMENT
1.
A Transaction…

2
Definition

◎ A transaction is a logical unit of work that contains

one or more SQL statements.
◎ Transactions are atomic units of work that can be
committed or rolled back.

3
Definition

◎ A transaction begins with the first executable SQL

statement.
◎ A transaction ends when it is committed or rolled
back, either explicitly with a COMMIT or ROLLBACK
statement or implicitly is issued.

4
2.
ACID Model

5
ATOMICITY

◎ a transaction is an atomic unit of processing and it is

either performed entirely or not at all

6
Consistency Preservation

◎ a transaction's correct execution must take the

database from one correct state to another

7
Isolation/Independence

◎ the updates of a transaction must not be made visible

to other transactions until it is committed (solves the
temporary update problem)

8
Durability (or Permanency)

◎ if a transaction changes the database and is

committed, the changes must never be lost because of
subsequent failure

9
Serializability

◎ transactions are considered serialisable if the effect of

running them in an interleaved fashion is equivalent to
running them serially in some order

10
3.
MySQL Transaction

11
Statements use in MySQL Transactions

◎ The START TRANSACTION or BEGIN statement begins

a new transaction.
◎ COMMIT commits the current transaction, making its
changes permanent.
◎ ROLLBACK rolls back the current transaction,
canceling its changes.
◎ The SET autocommit statement disables or enables
the default autocommit mode for the current session.
12
4.
Savepoint, Rollback
to Savepoint, Release
Savepoint

13
Savepoint

◎ The SAVEPOINT statement sets a named transaction

savepoint with a name of identifier.
◎ If the current transaction has a savepoint with the
same name, the old savepoint is deleted and a new
one is set.
◎ All savepoints of the current transaction are deleted if
you execute a COMMIT, or a ROLLBACK that does not
name a savepoint.
14
Savepoint

◎ A new savepoint level is created when a stored

function is invoked or a trigger is activated.
◎ The savepoints on previous levels become unavailable
and thus do not conflict with savepoints on the new
level.
◎ When the function or trigger terminates, any
savepoints it created are released and the previous
savepoint level is restored.
15
Rollback to Savepoint

◎ The ROLLBACK TO SAVEPOINT statement rolls back a

transaction to the named savepoint without
terminating the transaction.
◎ Modifications that the current transaction made to
rows after the savepoint was set are undone in the
rollback, but InnoDB does not release the row locks
that were stored in memory after the savepoint.
◎ Savepoints that were set at a later time than the
named savepoint are deleted.
16
Release Savepoint

◎ The RELEASE SAVEPOINT statement removes the

named savepoint from the set of savepoints of the
current transaction.
◎ No commit or rollback occurs.
◎ It is an error if the savepoint does not exist.

17
Example:

18
Example:

◎ Initialize a Transaction

◎ Establish a savepoint named ‘initial_save’:

19
Example:

◎ Perform an update to a row in the table:

◎ Changes:

20
Example:

◎ Revert the changes using rollback to savepoint:

◎ View the undone (original) data:

21
 “
“The ROLLBACK TO SAVEPOINT statement rolls back a
transaction to the named savepoint without terminating the
transaction. Modifications that the current transaction made to
rows after the savepoint was set are undone in the rollback,
but InnoDB does not release the row locks that were stored in
memory after the savepoint. (For a new inserted row, the lock
information is carried by the transaction ID stored in the row;
the lock is not separately stored in memory. In this case, the
row lock is released in the undo.)”
22
5.
Lock and Unlock
Tables

23
Lock and Unlock Tables

◎ MySQL enables client sessions to acquire table locks

explicitly for the purpose of cooperating with other
sessions for access to tables or to prevent other
sessions from modifying tables during periods when a
session requires exclusive access to them.
◎ A session can acquire or release locks only for itself.
◎ One session cannot acquire locks for another session
or release locks held by another session.
24
Lock and Unlock Tables

◎ LOCK TABLES explicitly acquires table locks for the

current client session.
◎ Table locks can be acquired for base tables or views.
◎ UNLOCK TABLES explicitly releases any table locks
held by the current session.
◎ LOCK TABLES implicitly releases any table locks held
by the current session before acquiring new locks.

25
6.
Concurrency
Problems

26
Lost Updates

◎ Lost updates occur when two or more transactions

select the same row and then update the row based
on the value originally selected. Each transaction is
unaware of other transactions. The last update
overwrites updates made by the other transactions,
which results in lost data.

27
Example (Lost Updates)

◎ Update QOH (quantity on hand)

28
Example (Lost Updates)

◎ Correct Result

29
Example (Lost Updates)

◎ Occurrence of Lost Updates

30
Uncommited Dependency

◎ Uncommitted dependency occurs when a second

transaction selects a row that is being updated by
another transaction. The second transaction is
reading data that has not been committed yet and
may be changed by the transaction updating the row.

31
Example (Uncommited Dependency)

◎ Transactions creating Uncommitted Dependency

32
Example (Uncommited Dependency)

◎ Correct execution of the transactions

33
Example (Uncommited Dependency)

◎ Uncommitted Dependency arises

34
Inconsistent Retrievals

◎ Inconsistent retrievals occurs when a second

transaction accesses the same row several times and
reads different data each time. Inconsistent analysis is
similar to uncommitted dependency in that another
transaction is changing the data that a second
transaction is reading.

35
Example (Inconsistent Retrievals)

◎ Retrieval during update

36
Example (Inconsistent Retrievals)

◎ Transaction Corrections

37
Example (Inconsistent Retrievals)

◎ Inconsistent Retrievals

38
7.
Scheduler

39
Scheduler

◎ The scheduler is a special DBMS process that establishes

the order in which the operations within concurrent
transactions are executed.
◎ The scheduler interleaves the execution of database
operations to ensure serializability and isolation of
transactions.
◎ To determine the appropriate order, the scheduler bases its
actions on concurrency control algorithms, such as locking
or time stamping methods, which are explained in the next
sections. 40
Scheduler

◎ A serializable schedule is a schedule of a

transaction’s operations in which the interleaved
execution of the transactions yields the same results
as if the transactions were executed in serial order.
◎ The scheduler also makes sure that the computer’s
central processing unit (CPU) and storage systems are
used efficiently.

41
8.
Concurrency Control
with Locking
Methods

42
Concurrency Control with Locking Methods

◎ A lock guarantees exclusive use of a data item to a

current transaction.
◎ A transaction acquires a lock prior to data access; the
lock is released (unlocked) when the transaction is
completed so that another transaction can lock the
data item for its exclusive use.
◎ All lock information is managed by a lock manager,
which is responsible for assigning and policing the
locks used by the transactions.
43
Lock Granularity

◎ Lock granularity indicates the level of lock use.

Locking can take place at the following levels:
database, table, page, row, or even field (attribute).

44
Lock Granularity

◎ Database-level lock
○ the entire database is locked, thus preventing the
use of any tables in the database by transaction T2
while transaction T1 is being executed.
○ This level of locking is good for batch processes,
but it is unsuitable for multiuser DBMSs.

45
Lock Granularity

◎ Table-level lock
○ the entire table is locked, preventing access to any
row by transaction T2 while transaction T1 is using
the table.
○ If a transaction requires access to several tables,
each table may be locked.
○ However, two transactions can access the same
database as long as they access different tables.

46
Lock Granularity

◎ Page-level lock
○ the DBMS will lock an entire diskpage.
○ A diskpage, or page, is the equivalent of a
diskblock, which can be described as a directly
addressable section of a disk.
○ Page-level locks are currently the most frequently
used multiuser DBMS locking method.

47
Lock Granularity

◎ Row-level lock
○ is much less restrictive than the locks discussed
earlier.
○ The DBMS allows concurrent transactions to
access different rows of the same table even when
the rows are located on the same page.
○ Modern DBMS automatically escalate a lock from
row level to page level lock when the application
session requests multiple locks on the same page.
48
Lock Granularity

◎ Field-level lock
○ allows concurrent transactions to access the same
row as long as they require the use of different
fields (attributes) within that row.

49
Lock Types

◎ Regardless of the level of locking, the DBMS may use

different lock types: binary or shared/exclusive.

50
Lock Types

◎ Binary Locks
○ has only two states: locked (1) or unlocked (0). If
an object—that is, a database, table, page, or
row—is locked by a transaction, no other
transaction can use that object.
○ If an object is unlocked, any transaction can lock
the object for its use.
○ As a rule, a transaction must unlock the object
after its termination.
51
Lock Types

◎ Binary Locks

52
Lock Types

◎ Shared/Exclusive Locks
○ The labels “shared” and “exclusive” indicate the
nature of the lock.
○ An exclusive lock exists when access is reserved
specifically for the transaction that locked the
object.
○ The exclusive lock must be used when the
potential for conflict exists.

53
Lock Types

◎ Shared/Exclusive Locks
○ A shared lock exists when concurrent transactions
are granted read access on the basis of a common
lock.
○ A shared lock produces no conflict as long as all
the concurrent transactions are read only.

54
Lock Types

◎ Shared/Exclusive Locks
○ A shared lock is issued when a transaction wants to
read data from the database and no exclusive lock is
held on that data item.
○ An exclusive lock is issued when a transaction wants to
update (write) a data item and no locks are currently
held on that data item by any other transaction.
○ Using the shared/exclusive locking concept, a lock can
have three states: unlocked, shared (read), and
exclusive (write).
55
9.
Two-phase Locking

56
Two-phase Locking

◎ defines how transactions acquire and relinquish locks.

◎ Two-phase locking guarantees serializability, but it
does not prevent deadlocks.

57
Two-phase Locking

◎ The two phases are:

○ A growing phase, in which a transaction acquires
all required locks without unlocking any data.
Once all locks have been acquired, the transaction
is in its locked point.
○ A shrinking phase, in which a transaction releases
all locks and cannot obtain any new lock.

58
Two-phase Locking

◎ The two-phase locking protocol is governed by the

following rules:

○ Two transactions cannot have conflicting locks.

○ No unlock operation can precede a lock operation
in the same transaction.
○ No data are affected until all locks are obtained—
that is, until the transaction is in its locked point.

59
Two-phase Locking

60
10.
Deadlocks

61
Deadlocks

◎ occurs when two transactions wait indefinitely for

each other to unlock data.
◎ Example: deadlock occurs when two transactions, T1
and T2, exist in the following mode:
○ T1 = access data items X and Y
○ T2 = access data items Y and X
○ If T1 has not unlocked data item Y, T2 cannot begin; if
T2 has not unlocked data item X, T1 cannot continue.

62
Deadlocks

63
Deadlocks

◎ The three basic techniques to control deadlocks are:

○ Deadlock prevention. A transaction requesting a
new lock is aborted when there is the possibility
that a deadlock can occur.
○ Deadlock detection. The DBMS periodically tests
the database for deadlocks
○ Deadlock avoidance. The transaction must obtain
all of the locks it needs before it can be executed.

64
10.
Concurrency Control
with Timestamping
Method

65
Timestamping

◎ approach to scheduling concurrent transactions

assigns a global, unique time stamp to each
transaction.
◎ time stamp value produces an explicit order in which
transactions are submitted to the DBMS.
◎ Time stamps must have two properties: uniqueness
and monotonicity.

66
Timestamping

◎ Wait/Die Scheme
○ If the transaction requesting the lock is the older of
the two transactions, it will wait until the other
transaction is completed and the locks are
released.
○ If the transaction requesting the lock is the
younger of the two transactions, it will die (roll
back) and is rescheduled using the same time
stamp.
67
Timestamping

◎ Wait/Die Scheme
○ in the wait/die scheme, the older transaction
waits for the younger to complete and release its
locks.

68
Timestamping

◎ Wound/Wait Scheme
○ If the transaction requesting the lock is the older of
the two transactions, it will preempt (wound) the
younger transaction (by rolling it back).
○ If the transaction requesting the lock is the
younger of the two transactions, it will wait until
the other transaction is completed and the locks
are released.

69
Timestamping

◎ Wound/Wait Scheme
○ in the wound/wait scheme, the older transaction
rolls back the younger transaction and
reschedules it.

70
Optimistic Approach

◎ based on the assumption that the majority of the

database operations do not conflict.
◎ requires neither locking nor time stamping techniques
◎ a transaction is executed without restrictions until it is
committed.
◎ Using an optimistic approach, each transaction moves
through two or three phases, referred to as read,
validation, and write.
71
Optimistic Approach

◎ Read Phase
○ the transaction reads the database, executes the
needed computations, and makes the updates to a
private copy of the database values.
○ All update operations of the transaction are
recorded in a temporary update file, which is not
accessed by the remaining transactions.

72
Optimistic Approach

◎ Validation Phase
○ the transaction is validated to ensure that the
changes made will not affect the integrity and
consistency of the database.
○ If the validation test is positive, the transaction
goes to the write phase.
○ If the validation test is negative, the transaction is
restarted and the changes are discarded.

73
Optimistic Approach

◎ Write Phase
○ the changes are permanently applied to the
database.

74
11.
Database Recovery
Management

75
Database Recovery

◎ Database recovery restores a database from a given

state (usually inconsistent) to a previously consistent
state.
◎ Recovery techniques are based on the atomic
transaction property: all portions of the transaction
must be treated as a single, logical unit of work in
which all operations are applied and completed to
produce a consistent database.

76
Critical Events

◎ Hardware/software failures.

◎ Human-caused incidents.

◎ Natural disasters.

77
Transaction Recovery

◎ write-ahead-log protocol
○ ensures that transaction logs are always written
before any database data are actually updated
○ This protocol ensures that, in case of a failure, the
database can later be recovered to a consistent
state, using the data in the transaction log.

78
Transaction Recovery

◎ Redundant transaction logs

○ (several copies of the transaction log) ensure that
a physical disk failure will not impair the DBMS’s
ability to recover data.

79
Transaction Recovery

◎ Database buffers
○ are temporary storage areas in primary memory
used to speed up disk operations.
○ To improve processing time, the DBMS software
reads the data from the physical disk and stores a
copy of it on a “buffer” in primary memory.

80
Transaction Recovery

◎ Database checkpoints
○ are operations in which the DBMS writes all of its
updated buffers to disk.

81