TRANSACTION PROCESSING

CONCURRENCY CONTROL

 DATABASE RECOVERY

 DATABASE SECURITY
TRANSACTION PROCESSING
 Def:
A Transaction is a program unit (
deletion, creation, updating etc)
whose execution preserves the
consistency of a database.
States of a transaction
 The keywords BEGIN TRANSACTION,
COMMIT, and ROLLBACK are available
in many data manipulation languages to
delimit transactions.
 If these delimiters are not used, the
entire program is usually regarded as a
single transaction, with the DBMS
automatically performing a COMMIT
when the program terminates correctly
and a ROLLBACK if it does not.
 Active, the initial state; the transaction stays in this state
while it is executing.
 Partially committed, after the final statement has been
executed.
 Failed, after the discovery that normal execution can no
longer proceed.
 Aborted, after the transaction has been rolled back and
the database has been restored to its state prior to the
start of the transaction.
 Committed, after successful completion.
 A transaction comprises a sequence of
operations consisting of read and/or
write actions to the database, followed
by a commit or abort action.
TRANSACTION PROCESSING
 To ensure that the above is met a
transaction must be
 Atomic

 Execute to completion

 Not execute at all

PROPERTIES OF A TRANSACTION
 There are properties that all
transactions should possess. The
four basic, or so-called ACID,
properties of a transaction
 Atomicity

 Consistency

 Isolation

 Durability
PROPERTIES OF A TRANSACTION

 atomicity
 Also known as the all nothing

property
 A transaction is an individual unit

that is either performed in its

entirety or not performed at all.
PROPERTIES OF A TRANSACTION
 Consistency
 The transaction must transform

the database from one

consistency state to another
consistency state
 PROPERTIES OF A TRANSACTION
 Isolation
 Transactions execute independently of

one another.
 Durability
 The effects of a successfully completed

transaction are permanently recorded

in the database and must never be lost
due to subsequent failure
 Transactions Management
 Scenario:
 transferring money from one account to
another in one bank requires the SQL
commands:
Transactions Management
 Transferring £100 from account 1234 to
Account 4567.
 Together they comprise a single
transaction.
 Potential problem:
 Database crash !!
Transaction integrity
 Crash may leave the Database in inconsistent
state
 in the example, it would be better if neither
of the commands had been executed.
 Transaction integrity
 demands that the effects of a transaction should
be either complete or not enacted at all.
Commit/Rollback protocol
 exist to support transaction integrity
 Commit
 is when changes to a Database are made
permanent
 when a Database crashes, any changes
that have not been committed will be lost
Commit
 We can issue an explicit commit
command when both of these update
commands have been issued
Rollback
 a mechanism to undo the effects of a
transaction.
 when issued all of the Database
changes since last commit are undone.
Rollback
 the Rollback in 4 undoes the effect of
the Update in 2
 because the Update has not been
committed
 – Suppose we issue a Commit
command
 Commit/Rollback

 The Commit command in 3 makes the

change permanent
CONCURRENCY CONTROL
 The process of managing simultaneous
operations on the database without
having them interfere with one another.
 CONCURRENCY CONTROL
 potential problems caused by
concurrency are:
 lost update problem,
 uncommitted dependency problem,

 inconsistent analysis problem.

 Concurrency problems
 The Lost Update Problem
 • The following situation might arise:
 1) TA reads Account record

1234. Value of balance is 150.

 2) TB reads Account record

1234. Value of balance is 150.

 3) TA increases to 250

(150+100).
The Lost Update Problem
 4) TB increases to 350 (150+200).
 5) TA writes back balance of 250.

 6) TB writes back balance of 350.

 The account should have a balance

•
of 450, not 350.
 • The update performed by TA has
been lost
The uncommitted dependency

 • When does it occur?

 Another transaction may start using
data that has not yet been
committed.
 – Effects: the 2nd transaction will use
false information.
The uncommitted dependency
 – Example
 TA
 Update Accounts
 Set Balance = Balance - 100
 Where Accno = 1234;
 If Balance < 0.00 Then Rollback Else Commit;
 TB
 Delete from Accounts
 Where Balance < 0.00;
The uncommitted dependency

 • Example
 1) TA retrieves Account 1234.
Value of balance is 50.
 2) TA reduces balance by
100. Leaving it as -50.
 3) TA writes back value of -
50.
uncommitted dependency

 4) TB retrieves Account 1234.

Balance is -50.
 5) TB deletes Account 1234 as it

has negative balance.

 6) TA rolls back update. Too late!

the account has been deleted

 TB used uncommitted data.
 Inconsistent Analysis

 A transaction accesses records while are

they being updated by another
transaction.
 Example
 2nd transaction transfers money from

one account to another.

 Hence, should have no effect on TA

result.
 Inconsistent Analysis

 TA
 Select Sum (Balance)
 From Account;

 TB
 Update Accounts
 Set Balance = Balance - 100 Where Accno = 3;
 Update Accounts
 Set Balance = Balance + 100 Where Accno = 1;
Inconsistent Analysis

 2nd transaction transfers money

from one account to another.
 Hence, should have no effect on

TA result.
 A procedure used to control concurrent
access to data. When one transaction is
accessing the database, a lock may
deny access to other transactions to
prevent incorrect results.
 Locking

 How to avoid all previous problems?

 Lock the object to prevent access by other
transactions
 A transaction releases the object when it
finishes with it
 Other transactions need to queue until the
object is released
 A transaction must claim a shared
(read) or exclusive (write) lock on a
data item before the corresponding
database read or write operation.
 Shared Locks

 A Shared lock S is placed on an object that is

being accessed for read only purposes
 many S locks may be placed
 an X lock must wait
Exclusive Locks
 An exclusive lock X, when an object is
being altered
 No other lock may be placed
 All transactions must wait
 The Locking Protocol

 Relate this to SQL:

 Many ‘read-only’ operations (e.g.
Select)
 One ‘update’ operation (e.g. Delete)
The Locking Protocol

 The Lost Update Problem:

 TA will place an X lock on Account
1234 before it starts update
The Locking Protocol

 The uncommitted dependency:

 TA will lock TB out from Account
1234 until it has completed the
rollback
The Locking Protocol

 The inconsistent analysis:

 TA will place an S lock on all of the
account records.
 Two-Phase Locking

 A transaction follows a 2 phase

locking protocol if all operations
precede the first unlock operations
in the transaction.
 According to this protocol every
transaction can be divided into two
phases
Two-Phase Locking

 Growing phase
 A transaction acquires all the

locks needed but can not release

any locks
 Shrinking Phase
 A transaction releases its locks

but cannot acquire any locks

 Normally, the transaction acquires some
locks, does some processing, and goes
on to acquire additional locks as
needed.
 However, it never releases any lock until
it has reached a stage where no new
locks are needed. The rules are:
 A transaction must acquire a lock on an item
before operating on the item. The lock may
be read or write, depending on the type of
access needed.
 Once the transaction releases a lock, it can
never acquire any new locks.
Problems with Locking

 Appropriate locking can guarantee

correctness, However, it also introduces
potential undesirable effects:
 Deadlock
 No transactions can proceed; each waiting
on lock held by another.
 Once deadlock occurs, the applications
involved cannot resolve the problem.
Instead, the DBMS has to recognize
that deadlock exists and break the
deadlock in some way.
 Unfortunately, there is only one way to
break deadlock: abort one or more of
the transactions.
 There are three general techniques for
handling deadlock:
 timeouts,
 deadlock prevention,
 deadlock detection and recovery.
 Timeouts
A transaction that requests a lock will wait
for only a system-defined period of time. If
the lock has not been granted within this
period, the lock request times out.
 Deadlock prevention
We order transactions using transaction
timestamps, Two algorithms have been
proposed:
One algorithm, Wait-Die, allows only an older
transaction to wait for a younger one,
otherwise the transaction is aborted (dies) and
restarted with the same timestamp,
so that eventually it will become the oldest
active transaction and will not die.
The second algorithm, Wound-Wait, uses
a symmetrical approach: only a younger
transaction can wait for an older one. If an
older transaction requests a lock held by
a younger one, the younger one is
aborted (wounded).
 Deadlock detection
 Deadlock detection is usually handled
by the construction of a wait-for graph
(WFG) that shows the transaction
dependencies; that is, transaction Ti is
dependent on Tj if transaction T holds
j

the lock on a data item that T is waiting

i

for.
 The WFG is a directed graph G = (N, E)
that consists of a set of nodes N and a
set of directed edges E, which is
constructed as follows:
 Create a node for each transaction.
 Create a directed edge T T, if transaction
Tis waiting to lock an item that is currently
locked by T
 Deadlock exists if and only if the WFG
contains a cycle
DATABASE RECOVERY
 Def:
 This is the process of restoring

the database to a consistency

state after a failure .
 DATABASE RECOVERY
Types of failure
 system crashes due to hardware or
software errors, resulting in loss of main
memory;
 media failures, such as head crashes or
unreadable media, resulting in the loss of
parts of secondary storage;
 n
 application software errors, such as
logical errors in the program that is
accessing the database, which cause
one or more transactions to fail;
 natural physical disasters, such as
fires, floods, earthquakes, or power
failures;
 carelessness or unintentional
destruction of data or facilities by
operators or users;
 sabotage, or intentional corruption or
destruction of data, hardware, or
software facilities.
Recovery Facilities
 The DBMS provides the following
facilities to recover from failure.
 Backup Mechanism -: Periodical

backup of the system

 Logging Facility -: Keeps truck of

the current state of the

transaction and the database
Recovery Facilities

 Checkpoint Facility -: enables

update to the database to be
made permanent
 Recovery manager -: Allows the
system t o restore the database
to a consistency state following a
failure
Recovery Techniques
 Deferred updates :
 This is where you use a log to

record all new transactions and

the log will be used to update the
database at a later stage.
 The deferred update techniques do not
physically update the database on disk
until after a transaction reaches its commit
point; then the updates are recorded in the
database. Before reaching commit, all
transaction updates are recorded in the
local transaction workspace (or buffers).
Recovery Techniques
 Immediate updates :
 This is where updates are made

to the records immediately and

the update is kept in both the log
and the database
 In the immediate update, the database
may be updated by some operations of a
transaction before the transaction reaches
its commit point. However, these
operations are typically recorded in the log
on disk by force writing before they are
applied to the database making recovery
still possible.
Recovery Techniques
 Shadow Paging
 Two page tables are maintained
during the life of a transaction
 The current page and the shadow
page
 When the transaction starts the
two tables are the same
Recovery Techniques
 The shadow page is not changed and
is used to restore the database in the
event of a failure
 The current page is used to record all
updates to the database
 When the transaction completes the
current page becomes the shadow
page and the shadow page is
garbage collected.
DATABASE SECURITY
 DEF:
 Mechanism that protects the
database against intentional or
accidental threats.
 It encompasses hardware ,

software , people and data

DATABASE SECURITY
 It is considered in relation to the
following situations:
 Theft

 Loss of Confidentiality

 Loss of privacy

 Loss of Integrity

 Loss of Availability
THEFT/FRAUD
 This the acquisition of data illegally
Confidentiality
 Refers to the need to maintain
secrecy over the data usually that
which is critical to an organization
Privacy
 Refers to the need to protect data
about individuals , loss would lead
to legal action taken against the
organization
Integrity
 Loss results in invalid and
corrupted data
Availability
 Data must be available to
authorized persons at an
appropriate time ( when as
required)
 Loss leads to the inability to access
data.
Database Security
 Measures that can be used to
safeguard databases from
anticipated threats
 Authorization

 Authentication

 Views or subschema

 encryption
Authentication
 Mechanisms that determines
whether a user is s/he what s/he
claims to be
 Establishing proof of identity
 Physical traits

 Pin codes

 Cards etc
 Authorization

 Also known as Access control

 This is the granting of rights and

privileges that enables a user to

have access to the system
Views or subschema
 A view is a virtual table that does
not exist in the database but is
produced upon request by
particular user
Encryption
 This is the encoding of the data by
a special algorithm that renders the
data unreadable by any program
without the decryption key.
 THE END

QUESTIONS????