Transaction management transparencies
Upcoming SlideShare
Loading in...5
×
 

Transaction management transparencies

on

  • 867 views

 

Statistics

Views

Total Views
867
Views on SlideShare
867
Embed Views
0

Actions

Likes
2
Downloads
25
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Transaction management transparencies Transaction management transparencies Presentation Transcript

  • Presented by :1.Haithm adam2.Mostafa hassan3.Mohamed siddig4.Mohamed zein elabdeen5.Omer salih
  • Outlines: importance of transactions. Properties of transactions. Concurrency Control Recovery Control Alternative models for long duration transactions.
  • 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
  • • 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
  • Four basic (ACID) properties of a transaction are:Atomicity : „All or nothing‟ property.Consistency: Must transform database from one consistentstate to another.Isolation : Partial effects of incomplete transactions shouldnot be visible to other transactions.Durability: Effects of a committed transaction arepermanent and must not be lost because of later failure.5
  • Concurrency ControlProcess of managing simultaneous operations on thedatabase without having them interfere with one another.Prevents interference when two or more users areaccessing databases simultaneously and at least one isupdating data for ConcurrencyNeed Concurrency controlThree examples of potential problems caused byconcurrency: Lost update problem. Uncommitted dependency problem. Inconsistent analysis problem.
  • Lost Update Problem Successfully completed update is overridden by anotheruser 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 unrepeatableOccurs when transaction reads several values but secondtransaction updates some of them during execution of first.read.T6 is totaling balances of account x (£100), account y (£50),and account z (£25).
  • Serial ScheduleSchedule where operations of each transaction are executedconsecutively without any interleaved operations from othertransactions.Precedence Graph
  • 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 conflictserializable.
  • Concurrency Control Techniques:Two basic concurrency control techniques: Locking, Timestamping.Both are conservative approaches: delay transactions incase they conflict with other transactions.Optimistic methods assume conflict is rare and only checkfor conflicts at commit.
  •  Locking Deadlock
  •  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.
  •  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.
  •  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
  •  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.
  • 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.
  •  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.
  •  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.
  • ts(T) < write_timestamp(x) ◦ x already written by younger transaction. ◦ Write can safely be ignored . Otherwise, operation is accepted and executed.
  •  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.
  •  Three phases: ◦ Read ◦ Validation ◦ Write
  •  Transactions should be durable, but we cannot prevent all sorts of failures: ◦ System crashes ◦ Power failures ◦ Disk crashes ◦ User mistakes ◦ Sabotage ◦ Natural disasters
  •  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
  •  Backup mechanism Logging ◦ Transaction records. ◦ Checkpoint records. Checkpoint Recovery manager
  •  Three main recovery techniques: ◦ Deferred Update ◦ Immediate Update ◦ Shadow Paging
  •  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.
  • 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 .
  •  carried out with one of the following Methods: ◦ Centralized . ◦ Linear. ◦ Distributed.
  •  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 .
  •  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.
  •  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 .
  •  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 .
  •  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
  •  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
  •  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.
  •  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.
  •  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.
  •  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.
  •  Look at five advanced transaction models: ◦ Nested Transaction Model ◦ Sagas ◦ Multi-level Transaction Model ◦ Dynamic Restructuring ◦ Workflow Models
  •  Transaction is viewed as a collection of related subtasks or subtransactions each of which may also contain any number of subtransactions.
  • “A sequence of (flat) transactions that can be interleaved with other transactions”. Saga has only one level of nesting .
  •  Closed nested transaction :atomicity enforced at the top-level. Open nested transactions : allow partial results of subtransactions to be seen outside transaction.
  •  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.
  •  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.
  •  Database system, thomas connolly http://en.wikipedia.org/wiki/Database_transa ction