Distributed Transaction Management…

Transaction: A collection of actions that transforms the

database from one consistent state to another state; during the
execution the database might be inconsistent.
 Example..

 Reserve a seat for a flight from LA to NY.

 Transfer money from your account to mine

 Withdraw money from an automatic teller machine

 Buy a book from amazon.com

 Example..

Consider the following SQL query for increasing by 10% the budget of the
CAD/CAM project that we discussed:
UPDATE PROJ
SET BUDGET = BUDGET * 1.1
WHERE PNAME = “CAD/CAM”

This query can be specified using the embedded SQL notation, as a

Transaction by giving it a name (e.g., BUDGET-UPDATE) and declarin
It as follows:
Begin-transaction BUDGET_UPDATE
Begin
EXEC SQL UPDATE PROJ
SET BUDGET = BUDGET * 1.1
WHERE PNAME=“CAD/CAM”
End
 Example Database.

Consider an airline reservation example with the

relations:
FLIGHT(FNO, DATE, SRC, DEST, STSOLD, CAP)
CUST(CNAME, ADDR, BAL)
FC(FNO, DATE, CNAME,SPECIAL)
Begin_transaction Reservation
begin
input(flight_no, date, customer_name);
EXEC SQL UPDATE FLIGHT
SET STSOLD = STSOLD + 1
WHERE FNO = flight_no AND DATE = date;
EXEC SQL INSERT
INTO FC(FNO, DATE, CNAME, SPECIAL);
VALUES (flight_no, date, customer_name, null);
output(“reservation completed”)
end . {Reservation}
Termination of Transactions

Begin_transaction Reservation
begin
input(flight_no, date, customer_name);
EXEC SQL SELECT STSOLD,CAP
INTO temp1,temp2
FROM FLIGHT
WHERE FNO = flight_no AND DATE = date;
if temp1 = temp2 then
output(“no free seats”);
Abort
else
EXEC SQL UPDATEFLIGHT
SET STSOLD = STSOLD + 1
WHERE FNO = flight_no AND DATE = date;
EXEC SQL INSERT
INTO FC(FNO, DATE, CNAME, SPECIAL);
VALUES(flight_no, date, customer_name, null);
Commit
output(“reservation completed”)
end if
end . {Reservation}
 Example..

Begin_transaction
Reservation
begin
input(flight_no, date, customer_name);
temp <- Read(flight_no(date).stsold);
if temp = flight(date).cap then
begin
output(“no free seats”);
Abort
end
else
begin
Write(flight(date).stsold, temp + 1);
Write(flight(date).cname, customer_name);
Write(flight(date).special, null);
Commit;
output(“reservation completed”)
end
end
Reservation
Properties of Transaction…
Atomicity [ALL OR NOTHING]
 Either all or none of the transaction's operations are performed.

 Atomicity requires that if a transaction is interrupted by a failure, its partial

results must be undone.

 The activity of preserving the transaction's atomicity in presence of transaction

aborts due to input errors, system overloads, or deadlocks is called transaction
recovery.

 The activity of ensuring atomicity in the presence of system crashes is called

crash recovery.
Properties of Transaction…
Consistency [no violation of integrity constraints ]

• A transaction which executes alone against a

consistent database leaves it in a consistent state.

• Transactions do not violate database integrity

constraints.
Properties of Transaction…

Isolation
Serializability
• If several transactions are executed concurrently,
the results must be the same as if they were
executed serially in some order.
Incomplete results
oAn incomplete transaction cannot reveal its
results to other transactions before its
commitment.
oNecessary to avoid cascading aborts.
Properties of Transaction…

Durability
Once a transaction commits, the system
must guarantee that the results of its
operations will never be lost, in spite of
subsequent failures.
Database recovery
Centralized Transaction Execution
 Distributed Transaction Execution

 Transaction Manager
 Record Manager
 Scheduler
Concurrency Control
 Concurrency Control…

 Concurrency control is the activity of coordinating

concurrent accesses to a database in a multi-user
database management system (DBMS)

Several Problems….
 Anomalies:
 Lost updates
 The effects of some transactions are not reflected on the
database.
Inconsistent retrievals
 A transaction, if it reads the same data item more than
once, should always read the same value.
Concurrency Control…
Scheduling Algorithms…

There are 3 basic methods for transaction concurrency

control.
 Locking (two phase locking - 2PL).
 Timestamp ordering
 Optimistic
 Hybrid
Locking

Majority Protocol
Local lock manager at each site administers
lock and unlock requests for data items stored
at that site.
When a transaction wishes to lock an un
replicated data item Q residing at site Si, a
message is sent to Si ‘s lock manager.
If Q is locked in an incompatible mode, then the
request is delayed until it can be granted.
When the lock request can be granted, the lock
manager sends a message back to the initiator
indicating that the lock request has been granted.
Majority Protocol (Cont.)
• In case of replicated data
– If Q is replicated at n sites, then a lock request message must be sent to more
than half of the n sites in which Q is stored.
– The transaction does not operate on Q until it has obtained a lock on a majority
of the replicas of Q.
– When writing the data item, transaction performs writes on all replicas.
• Benefit
– Can be used even when some sites are unavailable

• Drawback
– Requires 2(n/2 + 1) messages for handling lock requests, and (n/2 + 1) messages
for handling unlock requests.
– Potential for deadlock even with single item - e.g., each of 3 transactions may
have locks on 1/3rd of the replicas of a data.
 Biased Protocol…

Local lock manager at each site as in majority protocol,

however, requests for shared locks are handled differently
than requests for exclusive locks.
Shared locks. When a transaction needs to lock data
item Q, it simply requests a lock on Q from the lock
manager at one site containing a replica of Q.
Exclusive locks. When transaction needs to lock data
item Q, it requests a lock on Q from the lock manager at
all sites containing a replica of Q.
Advantage - imposes less overhead on read operations.
Disadvantage - additional overhead on writes
2 Phase Locking…

Centralized 2PL.
Distributed 2PL.
Centralized 2Phase Locking…
Distributed Phase Locking …
Timestamp Ordering…

• Timestamp (TS): a number associated with

each transaction
– Not necessarily real time
• Can be assigned by a logical counter
– Unique for each transaction
– Should be assigned in an increasing order for
each new transaction
 Timestamp Ordering…

• Timestamps associated with each database item

– Read timestamp (RTS) : the largest timestamp of the transactions
that read the item so far
– Write timestamp (WTS) : the largest timestamp of the transactions
that write the item so far
• After each successful read/write of object O by transaction
T the timestamp is updated
– RTS(O) = max(RTS(O), TS(T))
– WTS(O) = max(WTS(O), TS(T))
Timestamp Ordering…
• Given a transaction T
• If T wants to read(X)
– If TS(T) < WTS(X) then read is rejected, T has to abort
– Else, read is accepted and RTS(X) updated.
• For a write-read conflict, which direction does this protocol allow?

If T wants to write(X)

If TS(T) < RTS(X) then write is rejected, T has to abort

If TS(T) < WTS(X) then write is rejected, T has to abort

Else, allow the write, and update WTS(X) accordingly