Distributed Transaction Management

A distributed transaction is a database transaction in which two or more network hosts are involved. Usually, hosts provide transactional resources, while the transaction manager is responsible for creating and managing a global transaction that encompasses all operations against such resources.

Distributed transactions, as any other transactions, must have all four ACID (atomicity, consistency, isolation, durability) properties, where atomicity guarantees all-or-nothing outcomes for the unit of work (operations bundle).

Properties of Transactions

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.

CONSISTENCY

➠ no violation of integrity constraints

Internal consistency

➠ A transaction which executes alone against a

consistent database leaves it in a consistent state.

➠ Transactions do not violate database integrity

constraints.

Transactions are correct programs

Degree 0

➠ Transaction T does not overwrite dirty data of other

transactions

➠ Dirty data refers to data values that have been

updated by a transaction prior to its commitment

Degree 1

➠ T does not overwrite dirty data of other transactions

➠ T does not commit any writes before EOT

Degree 2

➠ T does not overwrite dirty data of other transactions

➠ T does not commit any writes before EOT

➠ T does not read dirty data from other transactions

n Degree 3

➠ T does not overwrite dirty data of other transactions

➠ T does not commit any writes before EOT

➠ T does not read dirty data from other transactions

➠ Other transactions do not dirty any data read by T

before T completes.

ISOLATION

➠ concurrent changes invisible È serializable

Serializability

➠ If several transactions are executed concurrently,

the results must be the same as if they were

executed serially in some order.

Incomplete results

➠ An incomplete transaction cannot reveal its

results to other transactions before its

commitment.

➠ Necessary to avoid cascading abort

DURABILITY

➠ committed updates persist

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