This document outlines transaction concepts including properties, concurrency control, and recovery control. It discusses the ACID properties of transactions and techniques for concurrency control including locking and timestamping. It covers concurrency issues like lost updates, inconsistent analysis, and deadlocks. Recovery control techniques like logging and checkpoints are also summarized. Alternative models for long transactions like nested transactions, sagas, and workflow models are briefly outlined.

1. Presented by :
1.Haithm adam
2.Mostafa hassan
3.Mohamed siddig
4.Mohamed zein elabdeen
5.Omer salih

2. Outlines:
 importance of transactions.
 Properties of transactions.
 Concurrency Control
 Recovery Control
 Alternative models for long duration transactions.

3. Transaction:
Action, or series of actions, carried out by user or
` application, which reads or updates contents of database.
 Application program is series of transactions with non-
database processing in between.
 Transforms database from one consistent state to another,
although consistency may be violated during transaction.
3

4. • have one of two outcomes:
– Success - transaction commits and database reaches a new
consistent state.
– Failure - transaction aborts, and database must be restored
to consistent state before it started.
– Such a transaction is rolled back or undone.
• Committed transaction cannot be aborted.
• Aborted transaction that is rolled back can be
restarted later.
4

5. Four basic (ACID) properties of a transaction are:
Atomicity : „All or nothing‟ property.
Consistency: Must transform database from one consistent
state to another.
Isolation : Partial effects of incomplete transactions should
not be visible to other transactions.
Durability: Effects of a committed transaction are
permanent and must not be lost because of later failure.
5

6. Concurrency Control
Process of managing simultaneous operations on the
database without having them interfere with one another.
Prevents interference when two or more users are
accessing databases simultaneously and at least one is
updating data
for Concurrency
Need Concurrency control
Three examples of potential problems caused by
concurrency:
Lost update problem.
Uncommitted dependency problem.
Inconsistent analysis problem.

7. Lost Update Problem
Successfully completed update is overridden by another
user
T1 withdrawing £10 from an account with balx, initially
£100.
T2 depositing £100 into same account.
Serially, final balance would be £190.
Inconsistent Analysis Problem
Sometimes referred to as dirty read or unrepeatable
Occurs when transaction reads several values but second
transaction updates some of them during execution of first.
read.
T6 is totaling balances of account x (£100), account y (£50),
and account z (£25).

8. Serial Schedule
Schedule where operations of each transaction are executed
consecutively without any interleaved operations from other
transactions.
Precedence Graph

9. Create:
node for each transaction;
a directed edge Ti  Tj, if Tj reads the value of an item
written by TI;
a directed edge Ti  Tj, if Tj writes a value into an item
after it has been read by Ti.
If precedence graph contains cycle schedule is not conflict
serializable.

10. Concurrency Control Techniques:
Two basic concurrency control techniques:
Locking,
Timestamping.
Both are conservative approaches: delay transactions in
case they conflict with other transactions.
Optimistic methods assume conflict is rare and only check
for conflicts at commit.

11.  Locking
 Deadlock

12.  Transaction uses locks to deny access to other
transactions and so prevent incorrect updates.
 Generally, a transaction must claim a shared (read) or
exclusive (write) lock on a data item before read or
write.
 Normal locking guarantees mutual exclusion but does
not guarantee serializability.

13.  Transaction follows 2PL protocol if all locking
operations precede first unlock operation in the
transaction.
 Two phases for transaction:
◦ Growing phase - acquires all locks but cannot release any
locks.
◦ Shrinking phase - releases locks but cannot acquire any new
locks.

14.  A situation when two (or more) transactions
are each waiting for locks held by the other to
be released.
 Three general techniques for handling
deadlock:
◦ Timeouts.
◦ Deadlock prevention.
◦ Deadlock detection and recovery

15.  locking methods generally prevent conflicts by making
transaction wait , if a transaction need an item that is already
locked, it may be wait until the item is released .
 With Timestamping the Transactions ordered globally so that
older transactions, transactions with smaller timestamps, get
priority in the event of conflict.
 Conflict is resolved by rolling back and restarting
transaction.
 No locks there no deadlock.

16. Timestamp:
A unique identifier created by DBMS that indicates
relative starting time of a transaction.
 Can be generated by using system clock at time transaction
started, or by incrementing a logical counter every time a
new transaction starts.

17.  Read/write proceeds only if last update on that data item was
carried out by an older transaction.
 Otherwise, transaction requesting read/write is restarted and
given a new timestamp.
 Also timestamps for data items:
◦ read-timestamp - timestamp of last transaction to read item;
◦ write-timestamp - timestamp of last transaction to write
item.

18.  Consider a transaction T with timestamp ts(T):
ts(T) < write_timestamp(x)
◦ x already updated by younger (later) transaction.
◦ Transaction must be aborted and restarted with a new
timestamp.
ts(T) < read_timestamp(x)
◦ x already read by younger transaction.
◦ Roll back transaction and restart it using a later timestamp.

19. ts(T) < write_timestamp(x)
◦ x already written by younger transaction.
◦ Write can safely be ignored .
 Otherwise, operation is accepted and executed.

20.  Versioning of data can be used to increase concurrency.
 Basic timestamp ordering protocol assumes only one version
of data item exists, and so only one transaction can access data
item at a time.
 Can allow multiple transactions to read and write different
versions of same data item, and ensure each transaction sees
consistent set of versions for all data items it accesses.

21.  Three phases:
◦ Read
◦ Validation
◦ Write

22.  Transactions should be durable, but we cannot
prevent all sorts of failures:
◦ System crashes
◦ Power failures
◦ Disk crashes
◦ User mistakes
◦ Sabotage
◦ Natural disasters

23.  Recovery manager responsible for atomicity
and durability.
 If failure occurs between commit and
database buffers being flushed to secondary
storage then, to ensure durability, recovery
manager has to redo (rollforward)
transaction’s updates.
 If transaction had not committed at failure
time, recovery manager has to undo (rollback)
any effects of that transaction for atomicity

25.  Backup mechanism
 Logging
◦ Transaction records.
◦ Checkpoint records.
 Checkpoint
 Recovery manager

26.  Three main recovery techniques:
◦ Deferred Update
◦ Immediate Update
◦ Shadow Paging

27.  It is a protocol that coordinates all the
processes that participate in a distributed
transaction on whether to commit or abort
(roll back) the transaction.
 has two types of nodes:
◦ coordinator.
◦ subordinate.

28. Has two phases:
The first phase :
is a PREPARE phase, where by the
coordinator of the transaction sends a
PREPARE message.
The second phase:
is decision-making phase, where the
coordinator issues a COMMIT message,
or an ABORT message .

29.  carried out with one of the following
Methods:
◦ Centralized .
◦ Linear.
◦ Distributed.

30.  communication is done through the
coordinator’s process only .
 no communication between subordinates.
 The coordinator transmit the PREPARE
message to the subordinates
 The coordinator receive votes from all
subordinates.
 the coordinator either abort or COMMIT .

31.  coordinator issues a PREPARE message to
all the subordinates
 if a subordinate is willing to COMMIT, sends
a YES VOTE .
 if that subordinate is not willing to
COMMIT, sends a NO VOTE.

32.  If all the subordinate vote to COMMIT, the
coordinator has to reach a global COMMIT
decision.
 the NO VOTE acts like a veto , only one NO
VOTE is needed to abort the transaction .

33.  After the coordinator reaches a vote, it has
to relay that vote to the subordinates.
 If the decision is COMMIT , the coordinator
sends a message to all the subordinates
informing them of the COMMIT.
 subordinates send an acknowledge (ACK )
Message to the coordinator.
 When the coordinator receives the ACK
messages, it ends the transaction .

34.  If the coordinator reaches an ABORT decision
, it sends an ABORT message to all the
subordinates.
 Noneed to send an ABORT message to the
subordinate(s) that gave a NO VOTE

35.  subordinates can communicate with each
other.
 The sites are labeled 1 to N, where the
coordinator is numbered as site 1 .
 the propagation of the PREPARE message is
done serially.
 node N is the one that issues the Global
COMMIT

36.  The coordinator sends a PREPARE message
to subordinate 2 .
 If subordinate 2 willing to ABORT,
then it sends a VOTE ABORT to
subordinate3 and the transaction is
aborted at this point.
 in case of COMMIT , subordinate 2 sends
its vote till node N is reached and issues its
vote.

37.  Node N sends either a GLOBAL ABORT or a
GLOBAL COMMIT to node N-1 .
 until the final vote to commit or abort
reaches the coordinator node.

39.  all the nodes communicate with each other.
 each node must have a list of all the
participating nodes .
 coordinator sends a PREPARE message to all
the participating nodes.

40.  When each subordinate gets the PREPARE
message, it sends its vote to all the other
subordinates.
 each node maintains a complete list of the
subordinates in every transaction.
 When a node receives all the votes from all
the subordinates, it can decide directly
COMMIT or abort.

42.  Look at five advanced transaction models:
◦ Nested Transaction Model
◦ Sagas
◦ Multi-level Transaction Model
◦ Dynamic Restructuring
◦ Workflow Models

43.  Transaction is viewed as a collection of related subtasks or
subtransactions each of which may also contain any number
of subtransactions.

44. “A sequence of (flat) transactions that can be interleaved with
other transactions”.
 Saga has only one level of nesting .

45.  Closed nested transaction :
atomicity enforced at the top-level.
 Open nested transactions :
allow partial results of subtransactions to be seen outside
transaction.

46.  split-transaction - splits transaction into two serializable
transactions and divides its actions and resources between
new transactions.
 join-transaction - performs reverse operation, merging
ongoing work of two or more independent transactions, as
though they had always been single transaction.

47.  Workflow is activity involving coordinated execution of
multiple tasks performed by different processing entities
(people or software systems).
 Two general problems involved in workflow systems:
◦ specification of the workflow.
◦ execution of the workflow.

48.  Database system, thomas connolly
 http://en.wikipedia.org/wiki/Database_transa
ction