Unit 4: Transaction

Transaction Processing Concepts

 Transactions
• A transaction is a unit of program execution that
accesses and possibly updates various data items.
• E.g., transaction to transfer $50 from account A to
account B:
1. read(A)
2. A := A – 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)

• Two main issues to deal with:

– Failures of various kinds, such as hardware failures and
system crashes
– Concurrent execution of multiple transactions
 Example of Fund Transfer (Cont.)
• Consistency requirement in above example:
– The sum of A and B is unchanged by the execution of the transaction
• In general, consistency requirements include
– Explicitly specified integrity constraints such as primary keys and foreign
keys
– Implicit integrity constraints
• e.g., sum of balances of all accounts, minus sum of loan amounts
must equal value of cash-in-hand
– A transaction must see a consistent database.
– During transaction execution the database may be temporarily
inconsistent.
– When the transaction completes successfully the database must be
consistent
• Erroneous transaction logic can lead to inconsistency
• Isolation requirement — if between steps 3 and 6,
another transaction T2 is allowed to access the partially
updated database, it will see an inconsistent database
(the sum A + B will be less than it should be).

T1 T2
1. read(A)
2. A := A – 50
3. write(A)
read(A), read(B), print(A+B)
4. read(B)
5. B := B + 50
6. write(B)

• Isolation can be ensured trivially by running

transactions serially
– That is, one after the other.
• However, executing multiple transactions concurrently
has significant benefits, as we will see later.
•
Transaction States
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 restored to its
state prior to the start of the transaction. Two options after it has been aborted:
– Restart the transaction
• Can be done only if no internal logical error
– Kill the transaction
• Committed – after successful completion.
 ACID Properties
A transaction is a unit of program execution that accesses and possibly updates various data
items. To preserve the integrity of data the database system must ensure:
• Atomicity. Either all operations of the transaction are properly
reflected in the database or none are.
• Consistency. Execution of a transaction in isolation preserves the
consistency of the database.
• Isolation. Although multiple transactions may execute
concurrently, each transaction must be unaware of other
concurrently executing transactions. Intermediate transaction results
must be hidden from other concurrently executed transactions.
– That is, for every pair of transactions Ti and Tj, it appears to Ti that either
Tj, finished execution before Ti started, or Tj started execution after Ti
finished.
• Durability. After a transaction completes successfully, the changes
it has made to the database persist, even if there are system failures.
 Schedule
• Schedule – a sequences of instructions that specify the chronological order
in which instructions of concurrent transactions are executed
– A schedule for a set of transactions must consist of all instructions of
those transactions
– Must preserve the order in which the instructions appear in each
individual transaction.
• A transaction that successfully completes its execution will have a commit
instructions as the last statement
– By default transaction assumed to execute commit instruction as its last
step
• A transaction that fails to successfully complete its execution will have an
abort instruction as the last statement
• Let T1 transfer $50 from A to B, and T2 transfer
10% of the balance from A to B.
• A serial schedule in which T1 is followed by T2 :
• Schedule 2: A serial schedule where T2 is
followed by T1

• The following concurrent schedule does not

preserve the value of (A + B ).
 Serializability
• Basic Assumption – Each transaction preserves database
consistency.
• Thus, serial execution of a set of transactions preserves database
consistency.
• A (possibly concurrent) schedule is serializable if it is equivalent
to a serial schedule. Different forms of schedule equivalence
give rise to the notions of:
1. Conflict serializability
2. View serializability
• We ignore operations other than read and write instructions
• We assume that transactions may perform arbitrary computations
on data in local buffers in between reads and writes.
• Our simplified schedules consist of only read and write
instructions.
 Conflicting Instructions
• Instructions li and lj of transactions Ti and Tj respectively,
conflict if and only if there exists some item Q accessed
by both li and lj, and at least one of these instructions
wrote Q.
1. li = read(Q), lj = read(Q). li and lj don’t conflict.
2. li = read(Q), lj = write(Q). They conflict.
3. li = write(Q), lj = read(Q). They conflict
4. li = write(Q), lj = write(Q). They conflict
• Intuitively, a conflict between li and lj forces a (logical)
temporal order between them.
• If li and lj are consecutive in a schedule and they do not
conflict, their results would remain the same even if they
 Conflict Serializability
• If a schedule S can be transformed into a schedule S’ by a series of swaps of non-
conflicting instructions, we say that S and S’ are conflict equivalent.
• We say that a schedule S is conflict serializable if it is conflict equivalent to a serial
schedule
• Schedule 3 can be transformed into Schedule 6, a serial schedule where T2 follows
T1, by series of swaps of non-conflicting instructions. Therefore Schedule 3 is
conflict serializable
• Example of a schedule that is not conflict serializable:
• We are unable to swap instructions in the above schedule to obtain either the serial
schedule < T3, T4 >, or the serial schedule < T4, T3 >.
 View Serializability
• Let S and S’ be two schedules with the same set of transactions. S and S’ are view
equivalent if the following three conditions are met, for each data item Q,
1. If in schedule S, transaction Ti reads the initial value of Q, then in
schedule S’ also transaction Ti must read the initial value of Q.
2. If in schedule S transaction Ti executes read(Q), and that value was
produced by transaction Tj (if any), then in schedule S’ also
transaction Ti must read the value of Q that was produced by the
same write(Q) operation of transaction Tj .
3. The transaction (if any) that performs the final write(Q) operation in
schedule S must also perform the final write(Q) operation in schedule S’.
• As can be seen, view equivalence is also based purely on reads and writes alone.
• A schedule S is view serializable if it is view equivalent to a serial schedule.
• Every conflict serializable schedule is also view serializable.
• Below is a schedule which is view-serializable but not conflict serializable.
• What serial schedule is above equivalent to?
• Every view serializable schedule that is not
• conflict serializable has blind writes
 Notions of Serializability
• The schedule below produces same outcome as the serial schedule < T1, T5 >,
yet is not conflict equivalent or view equivalent to it.
• Determining such equivalence requires
• analysis of operations other than read and write.

Testing for Serializability

• Consider some schedule of a set of transactions T1, T2, ..., Tn
• Precedence graph — a direct graph where the vertices are the
transactions (names).
• We draw an arc from Ti to Tj if the two transaction conflict, and Ti
accessed the data item on which the conflict arose earlier.
• We may label the arc by the item that was accessed.
• Example of a precedence graph
 Test for Conflict Serializability
A schedule is conflict serializable if and only if its
precedence graph is acyclic.
Cycle-detection algorithms exist which take order n2
time, where n is the number of vertices in the graph.
(Better algorithms take order n + e where e is the
number of edges.)
If precedence graph is acyclic, the serializability order
can be obtained by a topological sorting of the graph.
This is a linear order consistent with the partial
order of the graph.
For example, a serializability order for Schedule A
would be
T5  T1  T3  T2  T4
Are there others?
 Test for View Serializability
• The precedence graph test for conflict serializability cannot be used directly
to test for view serializability.
– Extension to test for view serializability has cost exponential in the size
of the precedence graph.
• The problem of checking if a schedule is view serializable falls in the class
of NP-complete problems.
– Thus, existence of an efficient algorithm is extremely unlikely.
• However practical algorithms that just check some sufficient conditions for
view serializability can still be used.
 Recoverable Schedules
Need to address the effect of transaction failures on concurrently running transactions.

• Recoverable schedule — if a transaction Tj reads a data item

previously written by a transaction Ti , then the commit operation of Ti
appears before the commit operation of Tj.
• The following schedule (Schedule 11) is not recoverable

• If T8 should abort, T9 would have read (and possibly shown to the

user) an inconsistent database state. Hence, database must ensure that
schedules are recoverable.
• Cascading rollback – a single transaction failure leads to a series of
transaction rollbacks. Consider the following schedule where none of
the transactions has yet committed (so the schedule is recoverable)

If T10 fails, T11 and T12 must also be rolled back.

• Can lead to the undoing of a significant amount of work
• Cascadeless schedules — cascading rollbacks cannot occur;
– For each pair of transactions Ti and Tj such that Tj reads a data
item previously written by Ti, the commit operation of Ti appears
before the read operation of Tj.
• Every Cascadeless schedule is also recoverable
• It is desirable to restrict the schedules to those that are cascadeless
 Recovery from Transaction failure
• Undo and Redo of Transactions
– undo(Ti) -- restores the value of all data items updated by Ti to their old values, going backwards from the
last log record for Ti
• Each time a data item X is restored to its old value V a special log record <Ti , X, V> is written out
• When undo of a transaction is complete, a log record
<Ti abort> is written out.
– redo(Ti) -- sets the value of all data items updated by Ti to the new values, going forward from the first log
record for Ti
• No logging is done in this case
Recovering from Failure
• When recovering after failure:
– Transaction Ti needs to be undone if the log
• Contains the record <Ti start>,
• But does not contain either the record <Ti commit> or <Ti abort>.
– Transaction Ti needs to be redone if the log
• Contains the records <Ti start>
• And contains the record <Ti commit> or <Ti abort>
• Suppose that transaction Ti was undone earlier and the <Ti abort> record was written to the log, and then a
failure occurs,
• On recovery from failure transaction Ti is redone
– Such a redo redoes all the original actions of transaction Ti including the steps that restored old values
• Known as repeating history
•
 Log-Based Recovery
• A log is a sequence of log records. The records keep information
about update activities on the database.
– The log is kept on stable storage
• When transaction Ti starts, it registers itself by writing a

<Ti start> log record

• Before Ti executes write(X), a log record

<Ti, X, V1, V2>

is written, where V1 is the value of X before the write (the old

value), and V2 is the value to be written to X (the new value).
• When Ti finishes it last statement, the log record <Ti commit> is written.
• Two approaches using logs
– Immediate database modification
– Deferred database modification.
 Immediate Database Modification
• The immediate-modification scheme allows updates of an
uncommitted transaction to be made to the buffer, or the
disk itself, before the transaction commits
• Update log record must be written before database item is
written
– We assume that the log record is output directly to stable storage
– (Will see later that how to postpone log record output to some
extent)
• Output of updated blocks to disk can take place at any time
before or after transaction commit
• Order in which blocks are output can be different from the
order in which they are written.
• The deferred-modification scheme performs updates to
buffer/disk only at the time of transaction commit
– Simplifies some aspects of recovery
 Checkpoints
• Redoing/undoing all transactions recorded in the log can be
very slow
– Processing the entire log is time-consuming if the system has run
for a long time
– We might unnecessarily redo transactions which have already
output their updates to the database.
• Streamline recovery procedure by periodically performing
checkpointing
1. Output all log records currently residing in main memory onto
stable
storage.
2. Output all modified buffer blocks to the disk.
3. Write a log record < checkpoint L> onto stable storage where L is
a
list of all transactions active at the time of checkpoint.
• During recovery we need to consider only the most recent transaction T i that started
before the checkpoint, and transactions that started after Ti.
– Scan backwards from end of log to find the most recent <checkpoint L> record
– Only transactions that are in L or started after the checkpoint need to be redone
or undone
– Transactions that committed or aborted before the checkpoint already have all
their updates output to stable storage.
• Some earlier part of the log may be needed for undo operations
– Continue scanning backwards till a record <Ti start> is found for every
transaction Ti in L.
– Parts of log prior to earliest <Ti start> record above are not needed for
recovery, and can be erased whenever desired.

 T1 can be ignored (updates already output to disk due to checkpoint)

 T2 and T3 redone.
T undone
 Deadlock Handling

• System is deadlocked if there is a set of transactions such that every

transaction in the set is waiting for another transaction in the set .

• Deadlock prevention protocols ensure that the system will never enter
into a deadlock state. Some prevention strategies:
– Require that each transaction locks all its data items before it
begins execution (pre-declaration).
– Impose partial ordering of all data items and require that a
transaction can lock data items only in the order specified by the
 Distributed Database
• A distributed database system consists of loosely coupled sites that share no
physical component
• Database systems that run on each site are independent of each other
• Transactions may access data at one or more sites
 Homogeneous Distributed Databases
• In a homogeneous distributed database
– All sites have identical software
– Are aware of each other and agree to cooperate in
processing user requests.
– Each site surrenders part of its autonomy in terms of right
to change schemas or software
– Appears to user as a single system
In a heterogeneous distributed database
– Different sites may use different schemas and software
• Difference in schema is a major problem for query processing
• Difference in software is a major problem for transaction
processing
– Sites may not be aware of each other and may provide only
limited facilities for cooperation in transaction processing
 Distributed Data Storage
• Assume relational data model
Replication
• System maintains multiple copies of data, stored in different sites, for
faster retrieval and fault tolerance.
Fragmentation
• Relation is partitioned into several fragments stored in distinct sites
Replication and fragmentation can be combined
• Relation is partitioned into several fragments: system maintains
several identical replicas of each such fragment.
Data Replication
• A relation or fragment of a relation is replicated if it is stored
redundantly in two or more sites.
• Full replication of a relation is the case where the relation is stored at
all sites.
• Fully redundant databases are those in which every site contains a
copy of the entire database
Advantages of Replication
• Availability: failure of site containing relation r does not result in
unavailability of r is replicas exist.
• Parallelism: queries on r may be processed by several nodes in parallel.
• Reduced data transfer: relation r is available locally at each site containing a
replica of r.
Disadvantages of Replication
• Increased cost of updates: each replica of relation r must be updated.
• Increased complexity of concurrency control: concurrent updates to distinct
replicas may lead to inconsistent data unless special concurrency control
mechanisms are implemented.
• One solution: choose one copy as primary copy and apply concurrency
control operations on primary copy
 Data Fragmentation
• Division of relation r into fragments r1, r2, …, rn which contain sufficient information to
reconstruct relation r.
• Horizontal fragmentation: each tuple of r is assigned to one or more fragments
• Vertical fragmentation: the schema for relation r is split into several smaller schemas
• All schemas must contain a common candidate key (or superkey) to ensure lossless join
property.
• A special attribute, the tuple-id attribute may be added to each schema to serve as a
candidate key.
Advantage and DisAdvantages
• Horizontal:
– allows parallel processing on fragments of a relation
– allows a relation to be split so that tuples are located where they are most frequently
accessed
– Vertical:
• allows tuples to be split so that each part of the tuple is stored where it is most
frequently accessed
• tuple-id attribute allows efficient joining of vertical fragments
• allows parallel processing on a relation
• Vertical and horizontal fragmentation can be mixed.
• Fragments may be successively fragmented to an arbitrary depth.
Data Transparency
• Data transparency: Degree to which system user may remain unaware of the
details of how and where the data items are stored in a distributed system
Consider transparency issues in relation to:
• Fragmentation transparency
• Replication transparency
• Location transparency
 Concurrency Control
• Modify concurrency control schemes for use in
distributed environment.
– We assume that each site participates in the execution of
a commit protocol to ensure global transaction atomicity.
– We assume all replicas of any item are updated
– Will see how to relax this in case of site failures later
 Single-Lock-Manager Approach
• System maintains a single lock manager that resides in a single chosen
site, say Si
• When a transaction needs to lock a data item, it sends a lock request to Si
and lock manager determines whether the lock can be granted immediately
• If yes, lock manager sends a message to the site which initiated the request
• If no, request is delayed until it can be granted, at which time a message is
sent to the initiating site
• The transaction can read the data item from any one of the sites at which a
replica of the data item resides.
• Writes must be performed on all replicas of a data item
Advantages of scheme:
• Simple implementation
• Simple deadlock handling
Disadvantages of scheme :
• Bottleneck: lock manager site becomes a bottleneck
• Vulnerability: system is vulnerable to lock manager site failure
 Distributed Lock Manager
• In this approach, functionality of locking is implemented by lock
managers at each site
– Lock managers control access to local data items
– But special protocols may be used for replicas
Advantage:
– work is distributed and can be made robust to failures
• Disadvantage:
– deadlock detection is more complicated
– Lock managers cooperate for deadlock detection
Several variants of this approach
– Primary copy
– Majority protocol
– Biased protocol
 Directory Systems
• Typical kinds of directory information
• Employee information such as name, id, email, phone, office
addr, ..
• Even personal information to be accessed from multiple places
e.g. Web browser bookmarks
White pages
• Entries organized by name or identifier
– Meant for forward lookup to find more about an entry
Yellow pages
• Entries organized by properties
• For reverse lookup to find entries matching specific requirements
When directories are to be accessed across an organization
• Alternative 1: Web interface. Not great for programs
• Alternative 2: Specialized directory access protocols
 Directory Access Protocols
• Most commonly used directory access protocol:
– LDAP (Lightweight Directory Access Protocol)
– Simplified from earlier X.500 protocol
– Question: Why not use database protocols like
ODBC/JDBC?
– Answer: Simplified protocols for a limited type of data
access, evolved parallel to ODBC/JDBC
– Provide a nice hierarchical naming mechanism similar to
file system directories
– Data can be partitioned amongst multiple servers for
different parts of the hierarchy, yet give a single view to
user – E.g. different servers for Bell Labs Murray Hill and
Bell Labs Bangalore
 Distributed Directory Trees
• Organizational information may be split into multiple directory information
trees
• Suffix of a DIT gives RDN to be tagged onto to all entries to get an overall
DN
• E.g. two DITs, one with suffix o=Lucent, c=USA and another with suffix
o=Lucent, c=India  Organizations often split up DITs based on
geographical location or by organizational structure
• Many LDAP implementations support replication (master-slave or
multimaster replication) of DITs (not part of LDAP 3 standard)
• A node in a DIT may be a referral to a node in another DIT
• E.g. Ou= Bell Labs may have a separate DIT, and DIT for o=Lucent may
have a leaf with ou=Bell Labs containing a referral to the Bell Labs DIT
• Refer alls are the key to integrating a distributed collection of directories
• When a server gets a query reaching a referral node, it may either
• Forward query to referred DIT and return answer to client, or
• Give referral back to client, which transparently sends query to referred DIT
 Implementation Issues for Distributed Databases
• Atomicity needed even for transactions that update data at multiple
sites
• The two-phase commit protocol (2PC) is used to ensure atomicity
– Basic idea: each site executes transaction until just before commit,
and the leaves final decision to a coordinator
– Each site must follow decision of coordinator, even if there is a
failure while waiting for coordinators decision
• 2PC is not always appropriate: other transaction models based on
persistent messaging, and workflows, are also used
• Distributed concurrency control (and deadlock detection) required
• Data items may be replicated to improve data availability