Transaction management transparencies

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

description

 

Transcript of Transaction management transparencies

Page 1: Transaction management transparencies

Transaction ManagementTransparencies

Presented by :1.Haithm adam2.Mostafa hassan3.Mohamed siddig4.Mohamed zein elabdeen5.Omer salih

Page 2: Transaction management transparencies

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

Page 3: Transaction management transparencies

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

Transaction Support

Page 4: Transaction management transparencies

• 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

Transaction Support

Page 5: Transaction management transparencies

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

Properties of Transactions

Page 6: Transaction management transparencies

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.

Page 7: Transaction management transparencies

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).

Page 8: Transaction management transparencies

Serial Schedule

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

Page 9: Transaction management transparencies

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.

Page 10: Transaction management transparencies

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.

Page 11: Transaction management transparencies

Locking Deadlock

Concurrency Control Techniques

Page 12: Transaction management transparencies

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.

Locking

Page 13: Transaction management transparencies

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.

2-phase lock

Page 14: Transaction management transparencies

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

Page 15: Transaction management transparencies

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.

Timestamping :

Page 16: Transaction management transparencies

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.

Timestamping

Page 17: Transaction management transparencies

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.

Timestamping:

Page 18: Transaction management transparencies

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.

Timestamping - Read(x) :

Page 19: Transaction management transparencies

ts(T) < write_timestamp(x)

◦ x already written by younger transaction.◦ Write can safely be ignored .

Otherwise, operation is accepted and executed.

Timestamping - Write(x)

Page 20: Transaction management transparencies

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.

Multiversion Timestamp Ordering

Page 21: Transaction management transparencies

Three phases:

◦ Read◦ Validation◦ Write

Optimistic Techniques:

Page 22: Transaction management transparencies

Recovery Transactions should be durable, but we cannot

prevent all sorts of failures:◦ System crashes◦ Power failures◦ Disk crashes◦ User mistakes◦ Sabotage◦ Natural disasters

Page 23: Transaction management transparencies

Recovery 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

Page 24: Transaction management transparencies

Example

Page 25: Transaction management transparencies

Recovery Facilities Backup mechanism Logging

◦ Transaction records.◦ Checkpoint records.

Checkpoint Recovery manager

Page 26: Transaction management transparencies

Main Recovery Techniques Three main recovery techniques:

◦ Deferred Update◦ Immediate Update◦ Shadow Paging

Page 27: Transaction management transparencies

Two phase commit

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.

Page 28: Transaction management transparencies

Two phase commit

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 .

Page 29: Transaction management transparencies

Methods carried out with one of the following

Methods:◦ Centralized .◦ Linear.◦ Distributed.

Page 30: Transaction management transparencies

The Centralized Two-Phase Commit 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 .

Page 31: Transaction management transparencies

First Phase 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.

Page 32: Transaction management transparencies

First Phase 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 .

Page 33: Transaction management transparencies

Second Phase 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 .

Page 34: Transaction management transparencies

Second Phase 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

Page 35: Transaction management transparencies

The Linear Two-Phase Commit

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

Page 36: Transaction management transparencies

First Phase

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.

Page 37: Transaction management transparencies

Second Phase 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.

Page 38: Transaction management transparencies
Page 39: Transaction management transparencies

The Distributed Two-Phase Commit

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.

Page 40: Transaction management transparencies

The Distributed Two-Phase Commit

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.

Page 41: Transaction management transparencies
Page 42: Transaction management transparencies

Advanced Transaction Models

Look at five advanced transaction models:

◦ Nested Transaction Model◦ Sagas◦ Multi-level Transaction Model◦ Dynamic Restructuring◦ Workflow Models

Page 43: Transaction management transparencies

Nested Transaction Model

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

Page 44: Transaction management transparencies

Sagas“A sequence of (flat) transactions that can be interleaved with other transactions”.

Saga has only one level of nesting .

Page 45: Transaction management transparencies

Multi-level Transaction Model

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

transaction.

Page 46: Transaction management transparencies

Dynamic Restructuring

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.

Page 47: Transaction management transparencies

Workflow Models

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.

Page 48: Transaction management transparencies

Database system, thomas connolly http://en.wikipedia.org/wiki/

Database_transaction

References: