distributed transactions management

Distributed Transactions Management

Basic concept of Transaction management Objective of Distributed transaction

management

Distributed Database Systems 1

management Model for Transaction management

Basic Concepts of TM

Transaction management deals with the problemof maintaining consistency of data in spite ofsystem failures and concurrent accesses to data.

A transaction consist of set of operations that thatA transaction consist of set of operations that thatperform a single logical unit of work. (entireprogram, a part of program or a single command)

ACID properties

If the transaction completes successfully thendatabase moves from one consistent state toanother.


Database in aconsistentstate

Database may betemporarily in aninconsistent stateduring execution

Database in aconsistentstate



state

BeginTransaction

EndTransaction

Execution ofTransaction

state

A transaction is made up of a sequence of readand write operations on the database, togetherwith some computational steps.

Transaction is unit of consistency and reliability.

Reliability- the resilience of a system to various


Reliability- the resilience of a system to varioustypes of failures and its capability to recover fromthem.

A recoverable DBMS always keeps the databasein a consistent state either by moving back to aprevious state or by moving forward to a newconsistent state.


Abort/commit

Rollback

concurrency transparency

failure transparency


failure transparency


Update employee salary by 20% for the employeeswhose emp-id is E001in employee relation

Begin-transaction salary_update



begin

EXEC SQL UPDATE EMPLOYEESET SALARY = SALARY*1.2WHERE EMP-ID = E001

end.

Objectives of Distributed Trans Mgmt.

CPU and main memory utilization should be improved

Response time should be minimized

Availability should be maximized Availability should be maximized

Communication cost should be minimized


Principles of Transactions

ATOMICITYall or nothing

CONSISTENCYCONSISTENCYno violation of integrity constraints

ISOLATIONconcurrent changes invisible serializable

DURABILITYcommitted updates persist 8Distributed Database Systems

Atomicity Either all or none of the transaction's

operations are performed.

Atomicity requires that if a transaction isinterrupted by a failure, its partial results mustbe undone.

The activity of preserving the transaction'satomicity in presence of transaction aborts dueto input errors, system overloads, or deadlocksis called transaction recovery.

The activity of ensuring atomicity in thepresence of system crashes is called crashrecovery.

9Distributed Database Systems

Consistency

Internal consistency A transaction which executes alone against a

consistent database leaves it in a consistentstate.state.

Transactions do not violate database integrityconstraints.

Transactions are correct programs


Consistency Degrees

Degree 0Transaction T does not overwrite dirty data of

other transactions

Dirty data refers to data values that have been Dirty data refers to data values that have been updated by a transaction prior to its commitment

Degree 1T does not overwrite dirty data of other

transactions

T does not commit any writes before EOT11Distributed Database Systems

Consistency Degrees (contd)

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

Degree 3

T does not overwrite dirty data of other transactionsT 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

Serializability If several transactions are executed

concurrently, the results must be the same as ifthey were executed serially in some order.they were executed serially in some order.

Incomplete results An incomplete transaction cannot reveal its

results to other transactions before itscommitment.

Necessary to avoid cascading aborts.


Isolation Example Consider the following two transactions:

T1: Read(x) T2: Read(x)x x+1 x x+1Write(x) Write(x)Commit Commit

Commit Commit

T1: Read(x) T1: Read(x)T1: x x+1 T1: x x+1T1: Write(x) T2: Read(x)T1: Commit T1: Write(x)T2: Read(x) T2: x x+1T2: x x+1 T2: Write(x)T2: Write(x) T1: CommitT2: Commit T2: Commit

Possible execution sequences:


SQL-92 Isolation LevelsPhenomena:

Dirty read

T1 modifies x which is then read by T2 before T1terminates; T1 aborts , T2 has read value which neverexists in the database.

Non-repeatable (fuzzy) read

T1 reads x; T2 then modifies or deletes x and commits.T1 tries to read x again but reads a different value orcant find it.

Phantom

T1 searches the database according to a predicatewhile T2 inserts new tuples that satisfy the predicate.


SQL-92 Isolation Levels (contd)

Read UncommittedFor transactions operating at this level, all three

phenomena are possible.

Read CommittedFuzzy reads and phantoms are possible, but

dirty reads are not.

Repeatable ReadOnly phantoms possible.

Anomaly SerializableNone of the phenomena are possible. 16Distributed Database Systems

Durability

Once a transaction commits, the systemmust guarantee that the results of itsoperations will never be lost, in spite ofsubsequent failures.subsequent failures.

Database recovery


Transaction Structure Flat transaction

Consists of a sequence of primitive operations embraced between a begin and end markers.

Begin_transaction Reservation

end. Nested transaction Nested transaction

The operations of a transaction may themselves be transactions.Begin_transaction Reservation

Begin_transaction Airline

end. {Airline}Begin_transaction Hotel

end. {Hotel}

end. {Reservation}18Distributed Database Systems

Nested Transactions

Have the same properties as their parents

may themselves have other nestedtransactions.

Introduces concurrency control and recovery Introduces concurrency control and recoveryconcepts to within the transaction.


Types

Closed nesting Subtransactions begin after their parents and finish

before them.

Commitment of a subtransaction is conditional upon

Nested Transactions

Commitment of a subtransaction is conditional uponthe commitment of the parent (commitment throughthe root).

Open nesting Subtransactions can execute and commit

independently.

Compensation may be necessary.Distributed Database Systems 20

Data from local sites

Local Transaction

Global Transaction

Data from Remote sites or multiple sites

Model for TM in Distributed System


Data from Remote sites or multiple sites

Transaction management in distributed DBMs ismore complicated than in centralized DBMS

Distributed DBMS must ensure the atomicity of theglobal transaction as well the as each ofcomponent subtransaction executed at the localsites.

1. Transaction ManagerCoordinates transactions on behalf of application programs bycommunicating with the scheduler and implements a particularstrategy for concurrency control

2. Concurrency control managerMaximize concurrency without allowing concurrently executing


Maximize concurrency without allowing concurrently executingtransactions to interfere with one another and thereby maintain theconsistency of the database as well as isolation property of thetransactions

3. Recovery managerPreserves the database in consistent state in case of failures

4. Buffer ManagerEfficient transfer of data between disk storage and main memory


All these modules exist in each local DBMS

A global transaction manager and Transactioncoordinator is required at each site to control theexecution of global transactions as well as of local


execution of global transactions as well as of localtransactions initiated at that site.


Model for TM in Distributed System Each site has its own local transaction manager, whose

function is to ensure the ACID properties of thosetransactions that execute at that site.

The various transaction managers cooperate to executeglobal transactions.

Each site contains two subsystems: Each site contains two subsystems:

1) The transaction manager manages the execution ofthose transactions (or subtransactions) that access datastored in a local site.

Each such transaction may be either a local transactionor part of a global transaction

2) The transaction coordinator coordinates the executionof the various transactions (both local and global) initiatedat that site.


Each transaction manager is responsible for

Maintaining a log for recovery purposes

Participating in an appropriate concurrency-control scheme to coordinate the concurrentexecution of the transactions executing at that


execution of the transactions executing at thatsite.


A transaction coordinator, is responsible for coordinatingthe execution of all the transactions initiated at that site.

For each such transaction, the coordinator is responsiblefor

Starting the execution of the transaction


Starting the execution of the transaction

Breaking the transaction into a number ofsubtransactions and distributing these subtransactions tothe appropriate sites for execution

Coordinating the termination of the transaction, whichmay result in the transaction being committed at all sitesor aborted at all sites.


When a user requests for the execution of an application(may be local or global) the application issues abegin_transaction primitive.

To execute a global application generated at site s1, thetransaction coordinator of s1 initiates the transaction andbreaks the transaction into a number of subtransactions.


It then involves multiple sites by consulting the globalsystem catalog for parallel execution of these transactionsat different sites.

Agents

The results retrieved from the parallel execution ofsubtransactions at multiple sites are integrated by thetransaction coordinator of site s1 and finally the transactionis terminated Distributed Database Systems 28

distributed transactions management

Documents