Unit iv -Transactions

Contents
Transaction and Concurrency Control: Transactions – Nested transactions –
Locks. Distributed Transactions: Introduction – Flat and nested distributed
transactions – Atomic commit protocols.

Transaction and Concurrency Control
● The goal of transactions is to ensure that all of the objects managed by a
server remain in a consistent state when they are accessed by multiple
transactions and in the presence of server crashes
● we use a banking example
● Each account is represented by a remote object whose interface, Account,
provides operations for making deposits and withdrawals and for enquiring
about and setting the balance.
● Each branch of the bank is represented by a remote object whose interface,
Branch, provides operations for creating a new account, for looking up an
account by name and for enquiring about the total funds at that branch.

Simple synchronization (without transactions)
Atomic operations at the server
● The use of threads allows operations from multiple clients to run
concurrently and possibly access the same objects. Therefore, the methods
of objects should be designed for use in a multi-threaded context.
● The use of the synchronized keyword, which can be applied to methods in
Java to ensure that only one thread at a time can access an object.
● public synchronized void deposit(int amount) throws RemoteException{
// adds amount to the balance of the account
}

● If one thread invokes a synchronized method on an object, then that
object is effectively locked, and another thread that invokes one of its
synchronized methods will be blocked until the lock is released.
● Without synchronization-resulting in an incorrect value
● Operations that are free from interference from concurrent operations
being performed in other threads are called atomic operations.
● The use of synchronized methods in Java is one way of achieving atomic
operations

Enhancing client cooperation by synchronization of server operations
● Clients may use a server as a means of sharing some resources. This is
achieved by some clients using operations to update the server’s objects and
other clients using operations to access them.
● The above scheme for synchronized access to objects provides all that is
required in many applications
● For example,when some clients are producers and others are consumers – the
consumers may have to wait until a producer has supplied
● The Java wait and notify methods introduced and allows threads to
communicate with one another in a manner that solves the above problems.

● Object.wait() to suspend a thread
Object.notify() to wake a thread up
● Consider the implementation of a shared Queue object with two methods: first
removes and returns the first object in the queue, and append adds a given object
to the end of the queue.
● The method first will test whether the queue is empty, in which case it will call
wait on the queue. If a client invokes first when the queue is empty, it will not get
a reply until another client has added something to the queue
● The append operation will call notify when it has added an object to the queue

2.Failure model for transactions
Lampson [1981] proposed a fault model for distributed transactions that accounts
forfailures of disks, servers and communication.
The model states the following:
● Writes to permanent storage may fail, either by writing nothing or by writing
a wrong value
● When a processor is faulty, it is made to crash so that it is prevented from
sending erroneous messages and from writing wrong values to permanent
storage
● A message may be lost, duplicated or corrupted. The recipient can detect
corrupted messages using a checksum.

Transactions
● In some situations, clients require a sequence of separate requests to a
server to be atomic in the sense that:
1. They are free from interference by operations being performed on behalf
of other concurrent clients.
2. Either all of the operations must be completed successfully or they must
have no effect at all in the presence of server crashes.

● Banking example to illustrate transactions.
● A client that performs a sequence of operations on a particular bank account
on behalf of a user will first lookUp the account by name and then apply the
deposit, withdraw and getBalance operations directly to the relevant account.
● Figure shows an example of a simple client transaction specifying a series of
related actions involving the bank accounts A, B and C.
● The first two actions transfer $100 from A to B and the second two transfer
$200 from C to B.
● A client achieves a transfer operation by doing a withdrawal followed by a
deposit.

● Transactions originate from database management systems. In that
context, a transaction is an execution of a program that accesses a
database.
● Transactions were introduced to distributed systems in the form of
transactional file servers such as XDFS
● In the context of a transactional file server, a transaction is an
execution of a sequence of client requests for file operations
● Transactions can be provided as a part of middleware.
● For example, CORBA provides the specification for an Object
Transaction Service [OMG 2003] with IDL interfaces allowing clients’
transactions to include multiple objects at multiple servers.

● In all of these contexts, a transaction applies to recoverable objects and is intended to be
atomic. It is often called an atomic transaction.
● There are two aspects to atomicity:
1.All or nothing: A transaction either completes successfully, in which case the effects of all
of its operations are recorded in the objects, or (if it fails or is deliberately aborted) has no
effect at all.
● Failure atomicity: The effects are atomic even when the server crashes
● Durability: After a transaction has completed successfully, all its effects are
saved in permanent storage.
2.Isolation: Each transaction must be performed without interference from other
transactions;

ACID properties
Härder and Reuter [1983] suggested the mnemonic ‘ACID’ to remember the
properties of transactions, which are as follows:
Atomicity: a transaction must be all or nothing;
Consistency: maintains data integrity constraints, leaving the data consistent.
Isolation:the transaction will not be changed by any other concurrent transaction
Durability:Once a transaction is completed and committed, its changes are persisted
permanently in the database.

● The coordinator gives each transaction an identifier, or TID.
● The client invokes the openTransaction method of the coordinator to introduce a
new transaction – a transaction identifier or TID is allocated and returned.
● At the end of a transaction, the client invokes the closeTransaction method to
indicate its end – all of the recoverable objects accessed by the transaction
should be saved.
● If, for some reason, the client wants to abort a transaction, it invokes the
abortTransaction method – all of its effects should be removed from sight.

● when the client makes a closeTransaction request. If the transaction has progressed
normally, the reply states that the transaction is committed
○ all of the changes requested in the transaction are permanently recorded
● When a transaction is aborted the parties involved must ensure that none of its effects
are visible to future transactions
We refer to a transaction as failing in both of the latter cases.
● Service actions related to process crashes
○ If a server process crashes unexpectedly, it is eventually replaced
● Client actions related to server process crashes
○ If a server crashes and is then replaced during the progress of a transaction, the
transaction will no longer be valid and the client must be informed via an exception
to the next operation

1.Concurrency control
● Two well-known problems of concurrent transactions
○ ‘lost update’ problem and
○ the ‘inconsistent retrievals’ problem.
The lost update problem
● This problem occurs when two transactions that access the same database items have their
operations interleaved in a way that makes the value of some database items incorrect
● Example:
○ The lost update problem is illustrated by the following pair of transactions on bank
accounts A, B and C, whose initial balances are $100, $200 and $300, respectively.
○ Transaction T transfers an amount from account A to account B. Transaction U
transfers an amount from account C to account B.
○ Amount transferred is calculated to increase the balance of B by 10%.

● The net effects on account B of executing the transactions T and U should be to
increase the balance of account B by 10% twice, so its final value is $242.
● Both transactions get the balance of B as $200 and then deposit $20. The result is
incorrect, increasing the balance of account B by $20 instead of $42.
● This is an illustration of the ‘lost update’ problem.
● U’s update is lost because T overwrites it without seeing it. Both transactions have read
the old value before either writes the new value.

Inconsistent retrievals
● Inconsistent retrievals occur when a transaction accesses data before and after another
transaction(s) finish working with such data.
● Inconsistent Retrievals Problem that occurs when in a transaction, two different values are
read for the same database item.
● Example:
○ Example related to a bank account in which transaction V transfers a sum from account
A to B and transaction W invokes the branchTotal method to obtain the sum of the
balances of all the accounts in the bank.
○ The balances of the two bank accounts, A and B, are both initially $200. The result of
branchTotal includes the sum of A and B as $300, which is wrong
○ W’s retrievals are inconsistent because V has performed only the withdrawal part of a
transfer at the time the sum is calculated.

Serial equivalence
● An interleaving of the operations of transactions in which the combined
effect is the same as if the transactions had been performed one at a
time in some order is a serially equivalent interleaving
● Example:
○ The figure shows one such interleaving in which the operations that affect the shared
account, B, are actually serial, for transaction T does all its operations on B before
transaction U does.
○ Another interleaving of T and U that has this property is one in which transaction U
completes its operations on account B before transaction T starts

We now consider the effect of serial equivalence in relation to the inconsistent retrievals problem,
in which transaction V is transferring a sum from account A to B and transaction W is obtaining the
sum of all the balances

Conflicting operations
● we consider a pair of operations, read and write.
● read accesses the value of an object and
● write changes its value
● The conflict rules for read and write operations are given in Figure

● Consider as an example the transactions T and U, defined as follows:
T: x = read(i); write(i, 10); write(j, 20);
U: y = read(j); write(j, 30); z = read (i);
● Ordering is not serially equivalent, because the pairs of conflicting operations are not done in
the same order at both objects. Serially equivalent orderings require one of the following two
conditions:
1. T accesses i before U and T accesses j before U.
2. U accesses i before T and U accesses j before T.
● Serial equivalence is used as a criterion for the derivation of concurrency control protocols
● Three alternative approaches to concurrency control are commonly used:
○ locking,
○ optimistic concurrency control and
○ timestamp ordering

2.Recoverability from aborts
● Servers must record all the effects of committed transactions and none of the effects of
aborted transactions
● Two problems associated with aborting transactions in the context of the banking example
○ dirty reads
○ premature writes
Operations are considered in two categories:
○ read operations and
○ write operations.
In our illustrations,
○ getBalance is a read operation and setBalance a write operation.

1.Dirty reads
● A dirty read occurs when a transaction reads data that has not yet been committed.
● The ‘dirty read’ problem is caused by the interaction between a read operation in one
transaction and an earlier write operation in another transaction on the same object
● T gets the balance of account A and sets it to $10 more, then U gets the balance of
account A and sets it to $20 more, and the two executions are serially equivalent.
● Now suppose that the transaction T aborts after U has committed.
● Then the transaction U will have seen a value that never existed, since A will be
restored to its original value.
● We say that the transaction U has performed a dirty read.

Recoverability of transactions
● If a transaction (like U) has committed after it has seen the effects of a transaction that
subsequently aborted, the situation is not recoverable
● The strategy for recoverability is to delay commits until after the commitment of any
other transaction whose uncommitted state has been observed.
● In our example, U delays its commit until after T commits. In the case that T aborts, then
U must abort as well.

Cascading aborts
● A situation in which the abort of one transaction forces the abort of another transaction to
prevent the second transaction from reading invalid (uncommitted) data.
● In the figure, suppose that transaction U delays committing until after T aborts. As we have
said, U must abort as well.
● Unfortunately, if any other transactions have seen the effects due to U, they too must be
aborted. The aborting of these latter transactions may cause still further transactions to be
aborted. Such situations are called cascading aborts
● To avoid cascading aborts, transactions are only allowed to read objects that were written
by committed transactions.

2.Premature writes
● An aborted operation is reset to the wrong value
● Example: we consider two setBalance transactions, T and U, on account A,
● Before the transactions, the balance of account A was $100. The two executions are serially
equivalent, with T setting the balance to $105 and U setting it to $110.
● If the transaction U aborts and T commits, the balance should be $105.
○ Some database systems implement the action of abort by restoring ‘before images’ of all
the writes of a transaction.
○ In our example, A is $100 initially, which is the ‘before image’ of T’s write; similarly,
$105 is the ‘before image’ of U’s write. Thus if U aborts, we get the correct balance of
$105.

● Now consider the case when U commits and then T aborts
○ The balance should be $110, but as the ‘before image’ of T’s write is
$100, we get the wrong balance of $100.
● Similarly, if T aborts and then U aborts,
○ the ‘before image’ of U’s write is $105 and we get the wrong balance
of $105 – the balance should revert to $100.
To ensure correct results in a recovery scheme that uses before images, write
operations must be delayed until earlier transactions that updated the same
objects have either committed or aborted.

Strict executions of transactions
● The executions of transactions are called strict if the service delays both read and write
operations on an object until all transactions that previously wrote that object have either
committed or aborted.
Tentative versions
● It must be designed so that any updates of objects can be removed if and when a transaction
aborts.
● To make this possible, all of the update operations performed during a transaction are done in
tentative versions of objects in volatile memory.
● Each transaction is provided with its own private set of tentative versions of any objects that
it has altered.
● All the update operations of a transaction store values in the transaction’s own private set
● The tentative versions are transferred to the objects only when a transaction commits, by
which time they will also have been recorded in permanent storage
● When a transaction aborts, its tentative versions are deleted.

Nested transactions
● A nested transaction forms a tree of transactions with the root being called a top-level
transaction and all other nodes called nested transactions (subtransactions)
● A nested transaction is a database transaction that is started by an instruction within the
scope of an already started transaction

● T is a top-level transaction that starts a pair of subtransactions, T1 and T2.
● The subtransaction T1 starts its own pair of subtransactions, T11 and T22.
● Also, subtransaction T2 starts its own subtransaction, T21, which starts another
subtransaction, T211.
● Subtransactions at the same level, such as T1 and T2, can run concurrently, but
their access to common objects is serialized
● Example, a transaction to deliver a mail message to a list of recipients could be
structured as a set of subtransactions, each of which delivers the message to one
of the recipients.
● If one or more of the subtransactions fails, the parent transaction could record
the fact and then commit, with the result that all the successful child transactions
commit.
● It could then start another transaction to attempt to redeliver the messages that
were not sent the first time.

Nested transactions have the following main advantages:
● Subtransactions at one level may run concurrently with other subtransactions at
the same level in the hierarchy. This can allow additional concurrency in a
transaction. When subtransactions run in different servers, they can work in
parallel
● Subtransactions can commit or abort independently. In comparison with a single
transaction, a set of nested subtransactions is potentially more robust

The rules for committing of nested transactions are rather subtle:
● A transaction may commit or abort only after its child transactions have completed.
● When a subtransaction completes, it makes an independent decision either to commit provisionally
or to abort. Its decision to abort is final.
● When a parent aborts, all of its subtransactions are aborted. For example, if T2 aborts then T21
and T211 must also abort, even though they may have provisionally committed.
● When a subtransaction aborts, the parent can decide whether to abort or not. In our example, T
decides to commit although T2 has aborted.
● If the top-level transaction commits, then all of the subtransactions that have provisionally
committed can commit too, provided that none of their ancestors has aborted. In our example, T’s
commitment allows T1, T11 and T12 to commit, but not T21 and T211 since their parent, T2,
aborted.

● In some cases, the top-level transaction may decide to abort because one or more of its
subtransactions have aborted. As an example, consider the following Transfer transaction:
○ Transfer $100 from B to A
○ a.deposit(100)
○ b.withdraw(100)
● When the two subtransactions both commit, the Transfer transaction can also commit.
● Now consider the case when the withdraw subtransaction aborts and the deposit subtransaction
commits
● We presume that the top-level (Transfer) transaction will decide to abort. The aborting of the
parent transaction causes the subtransactions to abort – so the deposit transaction is aborted and
all its effects are undone.

Locks
● A simple example of a serializing mechanism is the use of exclusive
locks.
● In this locking scheme, the server attempts to lock any object that is
about to be used by any operation of a client’s transaction.
● If a client requests access to an object that is already locked due to
another client’s transaction, the request is suspended and the client
must wait until the object is unlocked.

Two-phase locking.
● The first phase of each transaction is a ‘growing phase’, during which new
locks are acquired.
● In the second phase, the locks are released (a ‘shrinking phase’).
Strict two-phase locking
● Any locks applied during the progress of a transaction are held until the
transaction commits or aborts.
● The presence of the locks prevents other transactions reading or writing the
objects.
● When a transaction commits,to ensure recoverability, the locks must be held
until all the objects it updated have been written to permanent storage.

Many readers/single writer scheme
● It is preferable to adopt a locking scheme that controls the access to each object so
that there can be several concurrent transactions reading an object, or a single
transaction writing an object, but not both
Two types of locks are used
Read locks
● Before a transaction’s read operation is performed, a read lock should be set on
the object.
● As pairs of read operations from different transactions do not conflict, an
attempt to set a read lock on an object with a read lock is always successful.
● All the transactions reading the same object share its read lock (locks are
sometimes called shared locks.)
write locks
● Before a transaction’s write operation is performed, a write lock should be set on
the object.

The operation conflict rules tell us that:
● If a transaction T has already performed a read operation on a particular object,
then a concurrent transaction U must not write that object until T commits or
aborts.
● If a transaction T has already performed a write operation on a particular object,
then a concurrent transaction U must not read or write that object until T
commits or aborts.
To enforce condition 1, a request for a write lock on an object is delayed by the presence of
a read lock belonging to another transaction.
To enforce condition 2, a request for either a read lock or a write lock on an object is
delayed by the presence of a write lock belonging to another transaction.

Lock compatibility
The read lock allows other read locks, whereas the write lock does not. Neither

The rules for the use of locks in a strict two-phase locking
1.When an operation accesses an object within a transaction:
(a) If the object is not already locked, it is locked and the operation proceeds.
(b)If the object has a conflicting lock set by another transaction, the transaction must wait
until it is unlocked.
(c)If the object has a non-conflicting lock set by another transaction, the lock is shared and
the operation proceeds.
(d)If the object has already been locked in the same transaction, the lock will be promoted if
necessary and the operation proceeds. (Where promotion is prevented by a conflicting lock,
rule b is used.)
2. When a transaction is committed or aborted, the server unlocks all objects it locked for the
transaction.

● Lock promotion refers to the conversion of a lock to a stronger lock – that is, a
lock that is more exclusive
● For example, the CORBA Concurrency Control Service [OMG 2000b] can be used
to apply concurrency control on behalf of transactions or to protect objects
without using transactions
● A lockset’s lock method will acquire a lock or block until the lock is free; other
methods allow locks to be promoted or released
● CORBA transaction service tags all client requests in a transaction with the
transaction identifier.
● This enables a suitable lock to be acquired before each of the recoverable objects
is accessed during a transaction.
● The transaction coordinator is responsible for releasing the locks when a
transaction commits or aborts.

Lock implementation
● The granting of locks will be implemented by a separate object in the server that we
call the lock manager.
● The lock manager holds a set of locks, for example in a hash table.
● Each lock is an instance of the class Lock and is associated with a particular object.
● Each instance of Lock maintains the following information in its instance variables:
○ The identifier of the locked object;
○ The transaction identifiers of the transactions that currently hold the lock
(shared locks can have several holders);
○ lock type.

Lock Class
● The methods of Lock are synchronized so that the threads attempting to acquire
or release a lock will not interfere with one another.
● The acquire method carries out the rules and If another transaction holds the lock
in a conflicting mode, it invokes wait, which causes the caller’s thread to be
suspended until a corresponding notify
● When, eventually, the condition is satisfied, the remainder of the method sets the
lock appropriately:
○ if no other transaction holds the lock, just add the given transaction to the
holders and set the type;
○ else if another transaction holds the lock, share it by adding the given
transaction to the holders (unless it is already a holder);
○ else if this transaction is a holder but is requesting a more exclusive lock,
promote the lock.

LockManager class
● All requests to set locks and to release them on behalf of transactions are
sent to an instance of LockManager
● The setLock method’s arguments specify the object that the given
transaction wants to lock and the type of lock. It finds a lock for that object
in its hashtable or, if necessary, creates one. It then invokes the acquire
method of that lock.
● The unLock method’s argument specifies the transaction that is releasing its
locks. It finds all of the locks in the hashtable that have the given
transaction as a holder. For each one, it calls the release method.

Locking rules for nested transactions
● The aim of a locking scheme for nested transactions is to serialize access
to objects so that:
1. Each set of nested transactions is a single entity that must be prevented
from observing the partial effects of any other set of nested transactions.
2. Each transaction within a set of nested transactions must be prevented
from observing the partial effects of the other transactions in the set.

The second rule is enforced as follows:
• Parent transactions are not allowed to run concurrently with their child
transactions. If a parent transaction has a lock on an object, it retains the
lock during the time that its child transaction is executing. This means that
the child transaction temporarily acquires the lock from its parent for its
duration.
• Subtransactions at the same level are allowed to run concurrently, so when
they access the same objects, the locking scheme must serialize their access.

The following rules describe lock acquisition and release:
• For a subtransaction to acquire a read lock on an object, no other active transaction
can have a write lock on that object, and the only retainers of a write lock are its
ancestors.
• For a subtransaction to acquire a write lock on an object, no other active
transaction can have a read or write lock on that object, and the only retainers of
read and write locks on that object are its ancestors.
• When a subtransaction commits, its locks are inherited by its parent, allowing the
parent to retain the locks in the same mode as the child.
• When a subtransaction aborts, its locks are discarded. If the parent already retains
the locks, it can continue to do so.

Deadlocks
The use of locks can lead to deadlock.

● In the figure, Each of them acquires a lock on one account and then gets
blocked when it tries to access the account that the other one has
locked.
● This is a deadlock situation – two transactions are waiting, and each is
dependent on the other to release a lock so it can resume.
Definition of deadlock
Deadlock is a state in which each member of a group of transactions is
waiting for some other member to release a lock.

wait-for graph
● A wait-for graph can be used to represent the waiting relationships between
current transactions.
● In a wait-for graph the nodes represent transactions and the edges represent
wait-for relationships between transactions
● There is an edge from node T to node U when transaction T is waiting for
transaction U to release a lock

● A wait-for graph contains a cycle T -->U-->V -->T .
● Each transaction is waiting for the next transaction in the cycle.
● All of these transactions are blocked waiting for locks. None of the locks can
ever be released, and the transactions are deadlocked.
● If one of the transactions in a cycle is aborted, then its locks are released
and that cycle is broken.

● Now consider a scenario in which the three transactions T, U and V share a
read lock on an object C, and transaction W holds a write lock on object B, on
which transaction V is waiting to obtain a lock shown in figure

● The transactions T and W then request write locks on object C, and a deadlock situation
arises in which T waits for U and V, V waits for W, and W waits for T, U and V, as shown
in the figure
● each transaction can wait for only one object at a time, it may be involved in several
cycles. For example, transaction V is involved in two cycles: V ->W->T ->V and V ->W->V.
● Suppose that transaction V is aborted. This will release V’s lock on C and the two cycles
involving V will be broken.

Deadlock prevention
● One solution is to prevent deadlock
● An apparently simple but not very good way to overcome the deadlock problem is to lock
all of the objects used by a transaction when it starts.
● This approach unnecessarily restricts access to shared resources.
● Deadlocks can also be prevented by requesting locks on objects in a predefined order,
○ but this can result in premature locking and a reduction in concurrency.

Upgrade locks
● CORBA’s Concurrency Control Service introduces a third type of lock, called upgrade,
the use of which is intended to avoid deadlocks.
● Deadlocks are often caused by two conflicting transactions first taking read locks and
then attempting to promote them to write locks.
● A transaction with an upgrade lock on a data item is permitted to read that data item,
but this lock conflicts with any upgrade locks set by other transactions on the same
data item

Deadlock detection
● Deadlocks may be detected by finding cycles in the wait-for graph.
● The software responsible for deadlock detection can be part of the lock manager.
● It must hold a representation of the wait-for graph so that it can check it for cycles
from time to time.
● Edges are added to the graph and removed from the graph by the lock manager’s
setLock and unLock operations

● An edge T -->U is added whenever the lock manager blocks a request by transaction T
for a lock on an object that is already locked on behalf of transaction U
● When a lock is shared, several edges may be added.
● An edge T -->U is deleted whenever U releases a lock that T is waiting for and allows T
to proceed
● When a deadlock is detected, one of the transactions in the cycle must be chosen and
then be aborted.
● The choice of the transaction to abort is not simple.
● Some factors that may be taken into account are the age of the transaction and the
number of cycles in which it is involved

Timeouts
● Lock timeouts are a method for resolution of deadlocks that is commonly used.
● Each lock is given a limited period in which it is invulnerable.
● After this time, a lock becomes vulnerable. Provided that no other transaction is
competing for the object that is locked, an object with a vulnerable lock remains locked.
● However, if any other transaction is waiting to access the object protected by a
vulnerable lock, the lock is broken and the waiting transaction resumes.
● The transaction whose lock has been broken is normally aborted.

Increasing concurrency in locking schemes
Two approaches for increasing concurrency in locking scheme
● Two-version locking
○ The setting of exclusive locks is delayed until a transaction commits
● Hierarchic locks
○ Mixed-granularity locks are used

Two-version locking
● This is an optimistic scheme that allows one transaction to write tentative versions of
objects while other transactions read from the committed versions of the same
objects.
● Allows for more concurrency than read-write locks
○ writing transactions risk waiting or rejection when the commit
○ transactions cannot commit if other uncompleted transactions have read the
objects
○ these transactions must wait until the reading transactions have committed

● Three types of locks:
○ read lock,
○ write lock,
○ commit lock
● Before a transaction’s read operation is performed, a read lock must be set on the
object
○ the attempt to set a read lock is successful unless the object has a commit lock, in
which case the transaction waits
● Before a transaction’s write operation is performed, a write lock must be set on the
object – the attempt to set a write lock is successful unless the object has a write lock
or a commit lock, in which case the transaction waits.

● When the transaction coordinator receives a request to commit a transaction, it
attempts to convert all that transaction’s write locks to commit locks.
● If any of the objects have outstanding read locks, the transaction must wait until the
transactions that set these locks have completed and the locks are released

Main differences in performance between the two-version locking scheme and an
ordinary read-write locking scheme
● On the one hand, read operations in the two-version locking scheme are delayed only
while the transactions are being committed, rather than during the entire execution of
transactions
● On the other hand, read operations of one transaction can cause delays in committing
other transactions

Hierarchic locks
● The granularity of locks in a database refers to how much of the data is locked at one
time
● In some applications, the granularity suitable for one operation is not appropriate for
another operation.
● In our banking example, the majority of the operations require locking at the
granularity of an account.
● The branchTotal operation is different – it reads the values of all the account balances
and would appear to require a read lock on all of them.
● To reduce locking overhead, it would be useful to allow locks of mixed granularity to
coexist.

● Gray [1978] proposed the use of a hierarchy of locks with different granularities.
● At each level, the setting of a parent lock has the same effect as setting all the
equivalent child locks.
● This economizes on the number of locks to be set.
● In our banking example, the branch is the parent and the accounts are children

● Mixed-granularity locks could be useful in a diary system in which the data could be
structured with the diary for a week being composed of a page for each day and the
latter subdivided further into a slot for each hour of the day
● The operation to view a week would cause a read lock to be set at the top of this
hierarchy, whereas the operation to enter an appointment would cause a write lock to be
set on a given time slot.

● In Gray’s scheme, each node in the hierarchy can be locked, giving the owner of the lock
explicit access to the node and giving implicit access to its children.
● In our example, a read-write lock on the branch implicitly read-write locks all the
accounts.
● Before a child node is granted a read-write lock, an intention to read-write lock is set
on the parent node and its ancestors (if any).
note:
An intent lock is the lock the database server (lock manager) places on a higher
granularity object when a lower granularity object needs to be locked.

● In our banking example, the branchTotal operation requests a read lock on the branch,
which implicitly sets read locks on all the accounts.
● A deposit operation needs to set a write lock on a balance, but first it attempts to set
an intention to write lock on the branch.
● These rules prevent these operations running concurrently.
● Hierarchic locks have the advantage of reducing the number of locks when mixed
granularity locking is required.

DISTRIBUTED TRANSACTIONS
If a client transaction calls actions on multiple servers, it is said to be
distributed.
Distributed transactions can be structured in two different ways:
● Flat and nested distributed transactions
● Atomic commit protocols

Flat and nested distributed transactions
FLAT TRANSACTIONS :
● A flat transaction has a single initiating point(Begin) and a single end point(Commit or abort).
● They are usually very simple and are generally used for short activities rather than larger
ones.
● A client makes requests to multiple servers in a flat transaction. Transaction T, for example,
is a flat transaction that performs operations on objects in servers X, Y, and Z.
● Before moving on to the next request, a flat client transaction completes the previous one. As
a result, each transaction visits the server object in order.

NESTED TRANSACTIONS :
● A transaction that includes other transactions within its initiating point and a end point are
known as nested transactions. The nested transactions here are called sub-transactions.
● In a nested transaction, the top-level transaction can open subtransactions, and each
subtransaction can open further subtransactions down to any depth of nesting
● In the figure, the client transaction T that opens two subtransactions, T1 and T2, which
access objects at servers X and Y.
● The subtransactions T1 and T2 open further subtransactions T11, T12, T21, and T22, which
access objects at servers M, N and P.
● In the nested case, subtransactions at the same level can run concurrently, so T1 and T2 are
concurrent. The four subtransactions T11, T12, T21 and T22 also run concurrently.

Example:
● Consider a distributed transaction in which a client transfers $10 from account A to C and
then transfers $20 from B to D.
● Accounts A and B are at separate servers X and Y and accounts C and D are at server Z.
● If this transaction is structured as a set of four nested transactions as shown in figure, the
four requests (two deposits and two withdraws) can run in parallel and the overall effect can
be achieved with better performance than a simple transaction in which the four operations
are invoked sequentially.

The coordinator of a distributed transaction
● A client starts a transaction by sending an openTransaction request to a coordinator in
any server
● The coordinator that is contacted carries out the openTransaction and returns the
resulting transaction identifier (TID) to the client
● Transaction identifiers for distributed transactions must be unique within a distributed
system.
● A simple way to achieve this is for a TID to contain two parts: the identifier (for
example, an IP address) of the server that created it and a number unique to the
server.

● The coordinator is responsible for committing or aborting the transaction.
● Each of the servers that manages an object accessed by a transaction is a
participant in the transaction and provides an object we call the participant.
● Each participant is responsible for keeping track of all of the recoverable objects
at that server that are involved, in the transaction.
● The participants are responsible for cooperating with the coordinator in carrying
out the commit protocol
● During the progress of the transaction, the coordinator records a list of
references to the participants, and each participant records a reference to the
coordinator.

● The interface for Coordinator provides an additional method, join, which is used
whenever a new participant joins the transaction:
join(Trans, reference to participant)
Informs a coordinator that a new participant has joined the transaction Trans.
● The coordinator records the new participant in its participant list.
● In the figure 17.3 shows a client whose (flat) banking transaction involves accounts A, B,
C and D at servers BranchX, BranchY and BranchZ. The client’s transaction, T,
transfers $4 from account A to account C and then transfers $3 from account B to
account D.
● Each server is shown with a participant, which joins the transaction by invoking the join
method in the coordinator.
● When the client invokes one of the methods in the transaction, for example
b.withdraw(T, 3), the object receiving the invocation informs its participant object that
the object belongs to the transaction T.
● By the time the client calls closeTransaction, the coordinator has references to all of
the participants

Atomic commit protocols
One-phase atomic commit protocol.
○ In this protocol, the coordinator takes a decision
○ The coordinator communicates the commit or abort request to all of the participants
in the transaction
○ The coordinator repeats the request until all of them have acknowledged that they
have carried it out.
Drawback
○ This simple one-phase atomic commit protocol is inadequate, though, because it does
not allow a server to make a unilateral decision to abort a transaction when the client
requests a commit.
○ Finally, the coordinator may not know if a server has crashed and been replaced during
the progress of a distributed transaction

Two-phase atomic commit protocol.
First phase
● The coordinator is responsible for initiating the protocol
● In the first phase of the protocol, each participant votes for the transaction to be committed or
aborted. Once a participant has voted to commit a transaction, it is not allowed to abort it
● A participant in a transaction is said to be in a prepared state for a transaction if it will eventually
be able to commit it.
Second phase
● In the second phase of the protocol, every participant in the transaction carries out the joint
decision.
● If the client requests abortTransaction, or if the transaction is aborted by one of the
participants, the coordinator informs all participants immediately
● If all the participants vote to commit, then the decision is to commit the transaction.

● Interface of the participant.
The methods canCommit, doCommit and doAbort
● Coordinator interface.
The methods haveCommitted and getDecision
● The two-phase commit protocol consists of
○ voting phase
○ completion phase

Timeout actions in the two-phase commit protocol
○ The exchange of information between the coordinator and participants can
fail when one of the servers crashes, or when messages are lost.
○ Timeouts are used to avoid processes blocking forever. When a timeout
occurs at a process, it must take an appropriate action.
○ A participant may be delayed is when it has carried out all its client requests
in the transaction but has not yet received a canCommit?
○ The coordinator may be delayed when it is waiting for votes from the
participants.
○ As it has not yet decided the fate of the transaction it may decide to abort
the transaction after some period of time

Performance of the two-phase commit protocol
○ The coordinator, the participants and the communications between them do not
fail – the two-phase commit protocol involving N participants can be completed
with N canCommit? messages and replies, followed by N doCommit messages.
○ That is, the cost in messages is proportional to 3N, and the cost in time is three
rounds of messages
○ The two-phase commit protocol can cause considerable delays to participants in
the uncertain state. These delays occur when the coordinator has failed and
cannot reply to getDecision requests from participants
○ Three-phase commit protocols have been designed to alleviate such delays, but
they are more expensive in terms of the number of messages and the number of
rounds required for the normal (failure-free) case

Two-phase commit protocol for nested transactions
● The outermost transaction in a set of nested transactions is called the top-level transaction.
● Transactions other than the top-level transaction are called subtransactions

● A coordinator for a subtransaction will provide an operation to open a
subtransaction, together with an operation enabling that coordinator to enquire
whether its parent has yet committed or aborted

● A client starts a set of nested transactions by opening a top-level transaction with
an openTransaction operation, which returns a transaction identifier for the top-
level transaction.
● The client starts a subtransaction by invoking the openSubTransaction operation,
whose argument specifies its parent transaction.
● An identifier for a subtransaction must be an extension of its parent’s TID and all
subtransaction identifiers should be globally unique.
● The client makes a set of nested transactions come to completion by invoking
closeTransaction or abortTransaction on the coordinator of the top-level

● In the figure, Consider the top-level transaction T and its subtransactions and
Each subtransaction has either provisionally committed or aborted.
● For example, T12 has provisionally committed and T11 has aborted, but the fate
of T12 depends on its parent T1 and eventually on the top-level transaction, T.
● Although T21 and T22 have both provisionally committed, T2 has aborted and this
means that T21 and T22 must also abort.
● Suppose that T decides to commit in spite of the fact that T2 has aborted, and
that T1 decides to commit in spite of the fact that T11 has aborted.

● When a top-level transaction completes, its coordinator carries out a two-phase
commit protocol.
● The coordinator of each parent transaction has a list of its child subtransactions.
● When a nested transaction provisionally commits, it reports its status and the
status of its descendants to its parent.
● When a nested transaction aborts, it just reports abort to its parent without
giving any information about its descendants

● The top-level transaction plays the role of coordinator in the two-phase commit protocol
● The participant list consists of the coordinators of all the subtransactions in the tree that
have provisionally committed but do not have aborted ancestors
First phase:
● The coordinators of T, T1 and T12 are participants and will be asked to vote on the
outcome.
● If they vote to commit, then they must prepare their transactions by saving the state of the
objects in permanent storage.
Second phase
● The coordinator collects the votes and then informs the participants as to the outcome. When
it is complete, coordinator and participants will have committed or aborted their transactions.

● The two-phase commit protocol may be performed in either
○ A hierarchic manner or
○ A flat manner.
Hierarchic two-phase commit protocol
● In this approach, the two-phase commit protocol becomes a multi-level nested protocol.
● The coordinator of the top-level transaction communicates with the coordinators of the
subtransactions for which it is the immediate parent.
● It sends canCommit? messages to each of the latter, which in turn pass them on to the
coordinators of their child transactions.
● Each participant collects the replies from its descendants before replying to its parent.
● In our example, T sends canCommit? messages to the coordinator of T1 and then T1 sends
canCommit? messages to T12 asking about descendants of T1. The protocol does not include
the coordinators of transactions such as T2, which has aborted

● The first argument is the TID of the toplevel transaction, for use when preparing the data.
● The second argument is the TID of the participant making the canCommit? call
● For example, the coordinator of T12 is also the coordinator of T21, since they run in the same
server, but when it receives the canCommit? call, the second argument will be T1 and it will
deal only with T12.
● If a participant finds any subtransactions that match the second argument, it prepares the
objects and replies with a Yes vote.
● If it fails to find any, then it must have crashed since it performed the subtransaction and it
replies with a No vote.

Flat two-phase commit protocol
● In this approach, the coordinator of the top-level transaction sends canCommit? messages to
the coordinators of all of the subtransactions in the provisional commit list – in our example,
to the coordinators of T1 and T12.
● Unfortunately, this does not provide sufficient information to enable correct actions by
participants such as the coordinator at server N that have a mix of provisionally committed
and aborted subtransactions
● If N’s coordinator is just asked to commit T it will end up by committing both T12 and T21,
because, according to its local information, both have provisionally committed.
● This is wrong in the case of T21, because its parent, T2, has aborted.

● To allow for such cases, the canCommit? Operation for the flat commit protocol has a
second argument that provides a list of aborted subtransactions
● If the participant has any provisionally committed transactions that are descendants of
the top-level transaction, trans, it:
○ checks that they do not have aborted ancestors in the abortList, then prepares to
commit
○ aborts those with aborted ancestors;
○ sends a Yes vote to the coordinator.
● If the participant does not have a provisionally committed descendent of the toplevel
transaction, it must have failed since it performed the subtransaction and it sends a No

A comparison of the two approaches
● The hierarchic protocol has the advantage that at each stage, the participant
only need look for subtransactions of its immediate parent, whereas the flat
protocol needs to have the abort list in order to eliminate transactions whose
parents have aborted.
● Moss [1985] preferred the flat algorithm because it allows the coordinator
of the top-level transaction to communicate directly with all of the
participants, whereas the hierarchic variant involves passing a series of
messages down and up the tree in stages.

Timeout actions
● The two-phase commit protocol for nested transactions can cause the coordinator or a
participant to be delayed
● In our example, T22 is such a subtransaction – it has provisionally committed, but as its parent
T2 has aborted, it does not become a participant.
● To deal with such situations, any subtransaction that has not received a canCommit? message will
make an enquiry after a timeout period
● The getStatus operation allows a subtransaction to enquire whether its parent has committed or
aborted.
● To make such enquiries possible, the coordinators of aborted subtransactions need to survive for
a period

Unit iv -Transactions

More Related Content

What's hot (20)

Similar to Unit iv -Transactions (20)

More from Dhivyaa C.R (18)

Recently uploaded (20)

Unit iv -Transactions