Sem 4 (NEP 2020) Subject = DMC Unit = 3

* What is a Transaction?
= any action that reads from and/or writes to a database.
= logical unit of work that must be entirely completed or entirely aborted;
no intermediate states are acceptable.
= may consist of a simple statement or a series of related statements.
= A successful transaction changes the database from one consistent state to
another consistent state.
- A consistent database state is one in which all data integrity
constraints are satisfied.

* Transaction Properties (ACIDs Test)

1) Atomicity = all operations (SQL requests) of a transaction be completed; if
not, the transaction is aborted.
2) Consistency = the permanence of the database’s consistent state
3) Isolation = the data used during the execution of a transaction cannot be
used by a second transaction until the first one is completed.
4) Durability = once transaction changes are done (committed), they cannot be
undone or lost, even in the event of a system failure.
5) Serializability = the schedule for the concurrent execution of the
transactions yields consistent results.

* The trasaction log

- to keep track of all transactions that update the database.
- to be used by the DBMS for a recovery requirement
- The transaction log stores:
# 1) A record for the beginning of the transaction.
2) For each transaction component (SQL statement), it stores :
- The type of operation being performed (update, delete, insert).
- The names of the objects affected by the transaction (the name of the
table).
- The “before” and “after” values for the fields being updated.
- Pointers to the previous and next transaction log entries for the same
transaction.
3) The ending (COMMIT) of the transaction.

* Concurrency Control
- Meaning = The coordination of the simultaneous execution of transactions in a
multiuser database system
- Objective = to ensure the serializability of transactions in a multiuser
database environment.
- data integrity and consistency problems:
1) Lost updates
= occurs when two concurrent transactions, T1 and T2, are updating the
same data element and one of the updates is lost (overwritten by the other
transaction).
2) Uncommitted data
= occurs when two transactions, T1 and T2, are executed concurrently and
the first transaction (T1) is rolled back after the second transaction (T2) has
already accessed the uncommitted data—thus violating the isolation property of
transactions.
3) Inconsistent retrievals
= occurs when a transaction accesses data before and after another
transaction(s) finish working with such data.

* The Schedular:
- The scheduler is a special DBMS process that establishes the order in which
the operations within concurrent transactions are executed.
- aim is to ensure serializability and isolation of transactions.
- The scheduler’s main job is to create a serializable schedule of a
transaction’s operations.
- A serializable schedule = a schedule of a transaction’s operations in
which the interleaved execution of the transactions (T1,
 T2, T3, etc.) yields the same results as if the transactions were executed
in serial order (one after another).
- The scheduler also makes sure that the computer’s central processing unit
(CPU) and storage systems are used efficiently.
- Additionally, the scheduler facilitates data isolation to ensure that two
transactions do not update the same data
element at the same time. (e.g. table 10.11)
- following algorithms are used by DBMS to determine proper order:
1) locking
2) time stamping
3) optimistic
- Generally, transactions that are not serializable are executed on a first-
come, first-served basis by the DBMS. Otherwise, the scheduler’s main job is to
create a serializable schedule of a transaction’s operations.

* 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.
- The use of locks based on the assumption that conflict
between transactions is likely to occur is often referred to as pessimistic
locking.
- Most multiuser DBMSs automatically initiate and enforce locking procedures.
All lock information is managed by a lock manager, which is responsible for
assigning and policing the locks used by the transactions.

* Lock Granularity
- Lock granularity indicates the level of lock use.
- Locking can take place at the following levels:
1) database level
2) table level
3) page level
4) row level
5) field (attribute) level

- In a database-level lock, the entire database is locked. (figure 10.3)

- it prevents the use of any tables in the database by transaction T2 while
transaction Tl is being executed.
- This level of locking is good for batch processes, but it is unsuitable for
multiuser DBMSs.
- transactions T1 and T2 cannot access the same database concurrently even
when they use different tables.

- In a table-level lock, the entire table is locked. (figure 10.4)

- it prevents 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.
- they are less restrictive than database-level locks.
- they cause traffic jams when many transactions are waiting to access the
same table.
- Consequently, table-level locks are not suitable for multiuser DBMSs.

- In a page-level lock, the DBMS will lock an entire diskpage. (figure 10.5)
- A diskpage, or page, is the equivalent of a diskblock, which can be
described as a directly addressable section of a disk.
- A page has a fixed size, such as 4K, 8K, or 16K.
- A table can span several pages, and a page can contain several rows of one
or more tables.
- Page-level locks are currently the most frequently used multiuser DBMS
locking method.
- A row-level lock (figure 10.6) 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.
- it improves the availability of data.
- its management requires high overhead because a lock exists for each row in
a table of the database involved in a conflicting transaction.
- Modern DBMSs automatically escalate a lock from a row-level to a page-level
lock when the application session requests multiple locks
on the same page.

- The 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.
- Although field-level locking clearly yields the most flexible multiuser data
access, it is rarely implemented in a DBMS.
- because it requires an extremely high level of computer overhead and because
the row-level lock is much more useful in practice.

* Lock types
1) Binary Locks
- it has only two states
- Locked (1)
- 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.
- Such operations of locking and unlocking are automatically managed and
scheduled by the DBMS.
- binary locks are now considered too restrictive to yield optimal
concurrency conditions.

2) Shared/Exclusive Locks
- An exclusive lock exists when access is reserved specifically for the
transaction that locked the object.
- A shared lock exists when concurrent transactions are granted read access
on the basis of a common lock.
- a lock can have three states: unlocked, shared (read), and exclusive
(write).
- mutual exclusive rule: only one transaction at a time can own an exclusive
lock on the same object.
- locks prevent serious data inconsistencies but they can lead to two major
problems:
1) The resulting transaction schedule might not be serializable.
2) The schedule might create deadlocks.
- A deadlock occurs when two transactions wait indefinitely for each
other to unlock data.
- A database deadlock, which is equivalent to traffic gridlock in a big
city, is caused when two or more transactions wait for
each other to unlock data.

* Two-phase locking
- It guarantees serializability, but it does not prevent deadlocks.
- The two phases are: (figure 10.7)
1. 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.
2. A shrinking phase
- in which a transaction releases all locks and cannot obtain any new lock.
- rules:
# 1. Two transactions cannot have conflicting locks.
# 2. No unlock operation can precede a lock operation in the same transaction.
# 3. No data are affected until all locks are obtained—that is, until the
transaction is in its locked point.
- It increases the transaction processing cost.
- It might cause additional undesirable effects. e.g. the possibility of
creating deadlocks

* Deadlocks
- A deadlock occurs when two transactions wait indefinitely for each other to
unlock data.
- e.g. 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.
Consequently, T1 and T2 each wait for the other to unlock the required
data item.
- A deadlock is also known as a deadly embrace.
- Note:
1) Deadlocks are possible only when one of the transactions wants to obtain an
exclusive lock on a data item.
2) No deadlock condition can exist among shared locks.
- The three basic techniques to control deadlocks are:
1) Deadlock prevention
2) Deadlock detection
3) Deadlock Avoidance
- The choice of the best deadlock control method to use depends on the
database environment.
1) if the probability of deadlocks is low = deadlock detection is
recommended.
2) if the probability of deadlocks is high = deadlock prevention is
recommended.
3) if response time is not high on the system’s priority list = deadlock
avoidance might be employed.

* Concurrency control with timestamping methods

- The time stamping approach to scheduling concurrent transactions assigns a
global, unique time stamp to each transaction.
- The time stamp value produces an explicit order in which transactions are
submitted to the DBMS.
- Time stamps must have two properties:
1) uniqueness = it ensures that no equal time stamp values can exist
2) monotonicity = it ensures that time stamp values always increase
- The DBMS executes conflicting operations in time stamp order, thereby ensuring
serializability of the transactions.
- The disadvantage
1) Each value stored in the database requires two additional time stamp
fields:
- for the last time the field was read
- for the last update
2) it increases memory needs and the database’s processing overhead.
3) it demands a lot of system resources because many transactions might have
to be stopped, rescheduled, and restamped.

- two schemes to implement serializability (table 10.14)

1) Wait/die scheme
= Rule 1 : 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.
= Rule 2 : 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.
 = Here, in summary, the older transaction waits for the younger to
complete and release its locks

2) Wound/wait scheme
= Rule 1 : If the transaction requesting the lock is the older of the two
transactions, it will preempt (wound) the younger
transaction (by rolling it back). T1 preempts T2 when T1 rolls back T2. The
younger, preempted transaction is rescheduled using the same time stamp.
= Rule 2 : 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.
= Here, in summary, the older transaction rolls back the younger
transaction and reschedules it.

- To prevent deadlock situation when multiple locks are requested, DBMS

associates time-out value with each lock request.

* concurrency with optimistic methods

- assumption = the majority of the database operations do not conflict.
- it does not require any locking or time-stamping techniques.
- Here, each transaction moves through following three phases:
1) the read phase = transaction reads the database values, updates if required
and stores it in a temporary files privately.

2) the validation phase = transacation is validated for consistency and

integrity of the database. if validation is positive, transaction goes to the
write phase otherwise updates (in a temporary files privately) are discarded and
transaction is restarted.

3) the write phase = upon positive result of validation test, changes (that
are in temporary files) are applied into database permanently.

* Database recovery management - transaction recovery

- Database recovery restores a database from a given state (usually
inconsistent) to a previously consistent state.
- 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.
- critical erros that makes database non-operable / dis-integrited
1) hardware/software failures = one of the most common sources of database
problems
2) human-caused incidents = unintentional failures (carelessness by end users)
as well as intentional events (a more severe nature with data at serious risk)
3) Natural disasters = e.g. fires, earthquakes, floods, and power failures
- important concepts that affects the recovery process
1) write-ahead-log protocol
= transaction logs are always written before any database data are
actually updated.
2) Redundant transaction logs
= several copies of the transaction log
3) Database buffers
= temporary storage areas in primary memory used to speed up disk
operations
= first update data in buffers (a faster process) and then later on, write
all buffers to physical disk in a single operation.
4) Database checkpoints
= operations in which the DBMS writes all of its updated buffers to disk.
= result is the physical database and the transaction log will be in sync.
= automatically scheduled by the DBMS several times per hour

- two techniques of transaction recovery

- aim is to bring the database to a consistent state after a failure.
1) deferred-write technique = a deferred (late) update
- The transaction operations do not immediately update the physical
database. Instead, only the transaction log is updated.
- The database is physically updated only after the transaction reaches
its commit point, using information from the transaction log.
- ROLLBACK or undo operation is NOT required at all in case of transaction
abort.
2) write-through technique = an immediate update
- the database is immediately updated by transaction operations during
the transaction’s execution, even before the transaction reaches its commit
point.
- a ROLLBACK or undo operation (that uses the transaction log “before”
values) needs to be done in case of transaction abort.

***** * *****