Φραγή σε πολλαπλά επίπεδα λεπτομέρειας Τι αντικείμενα κλειδώνουμε?

Φραγή σε πολλαπλά επίπεδα λεπτομέρειας Τι αντικείμενα κλειδώνουμε? Το κλείδωμα δουλεύει σε κάθε περίπτωση, αλλά πρέπει να διαλέξουμε μικρά ή μεγάλα αντικείμενα? Αν κλειδώνουμε μεγάλα αντικείμενα (π.χ., relations) Χρειαζόμαστε λιγότερα locks Χαμηλή συγχρονικότητα Αν κλειδώνουμε μικρά αντικείμενα (π.χ., tuples, attributes) Χρειαζόμαστε περισσότερα locks Περισσότερη συγχρονικότητα Μπορούμε να έχουμε και τα δύο The bathroom metaphor: Relation A Relation B... Tuple A Tuple B Tuple C... Stall 1 Stall 2 Stall 3 Stall 4 restroom Disk Block A Disk Block B... DB DB DB hall 51

Φραγμοί σε ιεραρχίες από στοιχεία της ΒΔ Δενδροειδή δομή δεδομένων Ιεραρχία από αντικείμενα που επιδέχονται φραγμούς (σχέσεις, πλειάδες, ιδιότητες - relations, tuples, attributes) Δεδομένα οργανωμένα σε δέντρα (e.g. B-tree) Τρία επίπεδα από αντικείμενα της ΒΔ: Οι σχέσεις είναι τα μεγαλύτερα αντικείμενα που επιδέχονται φραγμούς Κάθε σχέση αποτελείται από ένα η περισσότερα δισκοσέλιδα (blocks) Κάθε block περιέχει μια ή περισσότερες πλειάδες Π.χ. τράπεζα, βάση δεδομένων με έγγραφα 52

Προειδοποιητικοί φραγμοί (warning locks) Οι προειδοποιητικοί φραγμοί δηλώνουν την πρόθεση (intention) να αποκτηθεί ένας φραγμός IS: πρόθεση να αποκτηθεί ένας κοινόχρηστος φραγμός IX: πρόθεση να αποκτηθεί ένας αποκλειστικός φραγμός Rules: Για να βάλουμε ένα S ή X lock, ξεκινάμε από την ρίζα Αν καθώς κατεβαίνουμε το δέντρο βρεθούμε στο στοιχείο που θέλουμε να φράξουμε, αιτούμαστε ένα S ή X lock επί του στοιχείου Αν το στοιχείο είναι πιο κάτω στην ιεραρχία, βάζουμε ένα μια προειδοποίηση στο κόμβο που βρισκόμαστε (IS ή IX) Προχωράμε στους θυγατρικούς κόμβους και επαναλαμβάνουμε την διαδικασία μέχρι να φτάσουμε στον επιθυμητό κόμβο. 53

Προειδοποιητικοί φραγμοί (warning locks) Για να αποφασίσουμε αν μπορεί να χορηγηθεί ένας φραγμός, χρησιμοποιούμε την μήτρα συμβατότητας. φραγμός που απαιτείται φραγμός που κατέχεται IS IX S X IS True True True False IX True True False False S True False True False X False False False False 54

Προειδοποιητικοί φραγμοί (warning locks) Ασυμβατότητες: Ένα IS σε κόμβο N είναι ασυμβίβαστο μόνο με ένα X lock στο N Ένα IX σε κόμβο N είναι ασυμβίβαστο με S και X στο N Πιθανές συγκρούσεις με IS/IS, IS/IX, IX/IS and IX/IX θα επιλυθούν σε κατώτερο επίπεδο Ένα S σε κόμβο N είναι συμβατό με IS και S Ένα X σε κόμβο N είναι ασυμβίβαστο με κάθε άλλο τύπο lock Μπορούμε να θέσουμε φραγμούς μόνο σε υπάρχοντα στοιχεία, και όχι σε αυτά που μπορεί να εισαχθούν αργότερα. Για να χειριστούμε εισαγωγές/διαγραφές: Μια δοσοληψία αποκτά exclusive lock στο A πριν το διαγράψει Κατά την εισαγωγή του A, η δοσοληψία αποκτά exclusive lock στο A 55

Πλειάδες φαντάσματα (phantoms) Τα phantoms είναι πλειάδες που θα έπρεπε να έχουν φραγή αλλά δεν έχουν, γιατί δεν υπήρχαν όταν αποκτήθηκε το lock Παράδειγμα: σχέση R (E#, name, ) constraint: E# is key χρήση κλειδώματος στις πλειάδες R E# Name. o1 55 Smith o2 75 Jones 56

Πλειάδες φαντάσματα (phantoms) T1: Insert <95,White, > into R T2: Insert <95,Black, > into R Για την εισαγωγή κάθε μιας από τις παραπάνω δεν υπάρχει lock στις πλειάδες και ο περιορισμός στο κλειδί δεν παραβιάζεται αν οι Τ1 και Τ2 γίνονται παράλληλα. Λύση: Για να αποφύγουμε την εμφάνιση πλειάδωνφαντασμάτων, πρέπει να θεωρήσουμε την εισαγωγή/διαγραφή μιας πλειάδας σαν πράξη εγγραφής επί της σχέσης (δηλαδή να λάβουμε αποκλειστικό φραγμό στην σχέση συνολικά και όχι μεμονωμένα στις πλειάδες). 57

Δενδρικό Πρωτόκολλο (Tree Protocol) Δενδρικά δεδομένα που όμως οι κόμβοι δεν έχουν ιεραρχική δομή βασισμένη στον αποκλεισμό. Ξένα μεταξύ τους κομμάτια που συνδέονται μέσω του μητρικού κόμβου π.χ. B-tree Διαφορετικές δυνατότητες για πολιτικές φραγμών 2PL δεν είναι καθόλου ευέλικτο σε αυτές τις περιπτώσεις: θέτει φραγμούς στο ριζικό κόμβο. Αν χρησιμοποιήσουμε ένα συνηθισμένο σύνολο φραγμών (S, X, U κλπ) σε επίπεδο κόμβου, η σύγχρονη χρήση του B- tree είναι σχεδόν αδύνατη: κάθε δοσοληψία ξεκινά από την ρίζα του δέντρου και κλειδώνονται όλοι οι κόμβοι στην διαδρομή (μαζί με την ρίζα). 58

Δενδρικό Πρωτόκολλο (Tree Protocol) Επιπλέον προβλήματα με το 2PL εισαγωγές/διαγραφές μπορεί να δημιουργήσουν επανεγγραφές στον ριζικό κόμβο. Exclusive ή update locks πρέπει να χρησιμοποιηθούν στην ρίζα οι πράξεις μόνο ανάγνωσης μπορούν να εκτελεστούν παράλληλα Αν άρουμε τον φραγμό στην ρίζα νωρίτερα, τότε θα είχαμε περισσότερες δυνατότητες αλλά θα παραβίαζε το 2PL και την σειριομορφία Χρειαζόμαστε εξειδικευμένα πρωτόκολλα που μπορεί να παραβιάζουν το 2PL. Πρέπει να εκμεταλλευτούμε την σειρά προσπέλασης στους κόμβους για να διασφαλίσουμε σειριομορφία. 59

Κανόνες προσπέλασης δενδροειδώς δομημένων δεδομένων Το Δενδρικό πρωτόκολλο (Tree Protocol) Υποθέσεις: έχουμε μόνο ένα είδους φραγμού, οι δοσοληψίες είναι συνεπείς, τα χρονοπρογράμματα είναι legal Κανόνες: 1. Ο πρώτος φραγμός κάθε δοσοληψίας μπορεί να αφορά οποιοδήποτε κόμβο του δέντρου. 2. Επόμενοι φραγμοί μπορούν να αποκτηθούν μόνο αν η δοσοληψία κατέχει εκείνη την στιγμή έναν φραγμό επί του μητρικού κόμβου. 3. Φραγμοί επί των κόμβων μπορούν να αρθούν οποιαδήποτε στιγμή. 4. Αν μια δοσοληψία άρει έναν φραγμό επί ενός κόμβου, δεν μπορεί να θέσει εκ νέου φραγμό σε αυτόν, ακόμα και αν εξακολουθεί να κατέχει φραγμό επί του μητρικού κόμβου. 60

Δενδρικό Πρωτόκολλο (Tree Protocol) Παράδειγμα 61

Λειτουργεί σωστά το δενδρικό πρωτόκολλο? Ορίζει εμμέσως μια σειριακή διάταξη εκτέλεσης των δοσοληψιών: αν στο χρονοδιάγραμμα S, οι Ti και Tj φράζουν ένα κόμβο από κοινού και η Ti τον φράζει πρώτη, τότε η Ti προηγείται της Tj Μπορούμε να φτιάξουμε ένα γράφο προήγησης για την αναπαράσταση αυτών σχέσεων προήγησης στο χρονοπρόγραμμα Αν δεν έχει κύκλους ο γράφος, τότε κάθε τοπολογική διάταξη δοσοληψιών αποτελεί ισοδύναμο σειριακό χρονοδιάγραμμα Ισχυρισμός: χρονοδιαγράμματα που ακολουθούν το δενδρικό πρωτόκολλο πάντα παράγουν γράφους χωρίς κύκλους αν δύο δοσοληψίες φράσσουν πολλά στοιχεία από κοινού, τότε όλα φράσσονται με την ίδια σειρά αν η Ti φράσσει την ρίζα πριν την Tj, τότε η Ti φράσσει κάθε κόμβο που είναι κοινός μεταξύ των Ti και Tj πριν την Tj. 62

Ensuring Serializability Μπορούμε να αποδείξουμε ότι, για κάθε χρονοδιάγραμμα S που ακολουθεί το δενδρικό πρωτόκολλο, υπάρχει κάποια σειριακή διάταξη ισοδύναμη με το S Σχεδιάγραμμα της απόδειξης: (με επαγωγή στον αριθμό των κόμβων) Base case: 1 node (root); follows by the previous observations Induction hypothesis: there is a serial order for all the transactions that lock nodes in any subtree containing more than one node Induction: Must merge the serial orders of the subtrees. Consider for each subtree the set of transactions that lock one or more nodes in the subtree. These sets have as common elements the transactions that lock the root. These transactions lock every common node in the same order they lock the root. Build a serial order for the entire set by starting with the transactions that lock the root in the appropriate order. The rest only need to be placed consistently with the serial order of their subtrees. 63

Ensuring Serializability Example: Assume there are 10 transactions, T 1, T 2,, T 10 of which T 1, T 3, T 4, T 6 lock the root in this order. Assume that the root node has two children nodes: first node is locked by the transactions with an odd index and T 4 and the second is locked by the transactions with an even index and T 3. Order in the 1 st subtree: T 9, T 1, T 5, T 7, T 3,T 4 Order in the 2 nd subtree: T 8, T 3, T 10, T 4, T 2, T 6 T 5 T 2 T 9 T 1 T 7 T 4 T 6 T 8 T 10 T 3 64

Έλεγχος συγχρονικότητας με χρονοσήμανση (Timestamp-based Concurrency Control) Βασικές ιδέες: Σε κάθε δοσοληψία βάζουμε μια «χρονοσήμανση» (timestamp) Καταγράφονται τα χρονόσημα των δοσοληψιών που έγραψαν ή διάβασαν τελευταίες ένα στοιχείο της ΒΔ Συγκρίνουμε αυτές τις τιμές με τα χρονόσημα των δοσοληψιών για να διασφαλίσουμε ότι το σειριακό χρονοδιάγραμμα με βάση τα χρονόσημα είναι ισοδύναμο με το πραγματικό χρονοδιάγραμμα των δοσοληψιών Αισιόδοξη (optimistic) προσέγγιση: υποθέτει ότι δεν θα προκύψει μησειριόμορφη συμπεριφορά και τα προβλήματα επιδιορθώνονται αν υπάρξει κάποια παραβίαση η μόνη θεραπεία είναι η ακύρωση και επανεκκίνηση Οι μέθοδοι κλειδώματος είναι απαισιόδοξες (pessimistic) και αποτρεπτικές (preventive). Ο αισιόδοξος χρονοπρογραμματισμός είναι καλύτερος από τις φραγές όταν πολλές δοσοληψίες κάνουν μόνο ανάγνωση. 65

Χρονόσημα (Timestamps) Κάθε δοσοληψία T αποδίδεται ένα μοναδικό χρονόσημο (unique timestamp) TS(T) Τα χρονόσημα αποδίδονται με αύξουσα σειρά όταν οι δοσοληψίες αρχίζουν Τα χρονόσημα μπορούν να παράγονται με δύο διαφορετικούς τρόπους: χρησιμοποιώντας το ρολόι του συστήματος χρησιμοποιώντας έναν μετρητή που τηρεί ο χρονοδιαγραμματιστής (scheduler), ο οποίος αυξάνεται κατά 1 κάθε φορά που ξεκινά μια δοσοληψία O scheduler πρέπει να τηρεί έναν πίνακα με τις ενεργές δοσοληψίες την τρέχουσα χρονική στιγμή και τα αντίστοιχα χρονόσημά τους. 66

Χρονόσημα (Timestamps) Για να χρησιμοποιήσουμε χρονόσημα ως μέθοδο έλεγχου συγχρονικότητας, πρέπει να συσχετίσουμε κάθε στοιχείο της ΒΔ με δύο χρονόσημα και ένα επιπλέον bit: RT(X): χρόνος ανάγνωσης του X, το μεγαλύτερο από τα χρονόσημα των δοσοληψιών που έχουν διαβάσει το Χ WT(X): χρόνος εγγραφής τουx, το μεγαλύτερο από τα χρονόσημα των δοσοληψιών που έχουν γράψει το Χ C(X): bit οριστικοποίησης για το X, είναι 1 αν-ν η πιο πρόσφατη δοσοληψία που έγραψε το Χ έχει ήδη οριστικοποιηθεί Το bit αυτό χρησιμοποιείται για την αποφυγή της κατάστασης όπου μια δοσοληψία Τ διαβάζει δεδομένα τα οποία γράφει μια άλλη δοσοληψία U και αργότερα η U ακυρώνεται (dirty read on uncommitted data) 67

Προβλήματα Ο scheduler υποθέτει ότι η σειρά χρονοσήαμανσης των δοσοληψιών είναι επίσης η σειριακή διάταξη με την οποία πρέπει να φαίνεται πως εκτελούνται Ο scheduler πρέπει ότι κάθε φορά που γίνεται μια ανάγνωση ή εγγραφή, αυτό που συμβαίνει στον πραγματικό χρόνο θα μπορούσε να είχε συμβεί αν κάθε δοσοληψία είχε εκτελεστεί στιγμιαία την χρονική στιγμή του χρονόσημού της. Σε αντίθετη περίπτωση μπορεί να προκύψουν δύο ειδών προβλήματα: Καθυστερημένη ανάγνωση: Η T προσπαθεί να διαβάσει το X, αλλά ο χρόνος εγγραφής WT(X) φανερώνει ότι η τρέχουσα τιμή του Χ εγγράφηκε μετά την θεωρητική εκτέλεση της T, δηλαδή TS(T) < WT(X). Η T δεν πρέπει να διαβάσει το X και ο scheduler πρέπει να ακυρώσει την T. Καθυστερημένη εγγραφή: Η T tries προσπαθεί να γράψει το X, αλλά ο χρόνος διαβάσματος RT(X) φανερώνει ότι κάποια άλλη δοσοληψία έπρεπε να είχε διαβάσει την τιμή που γράφτηκε από την T αλλά αντί αυτής διάβασε κάποια άλλη τιμή, δηλαδή WT(X) < TS(T) < RT(X) 68

Προβλήματα Καθυστερημένη ανάγνωση U γράφει το Χ Τ διαβάζει το Χ έναρξη της Τ έναρξη της U Καθυστερημένη εγγραφή U διαβάζει το Χ Τ γράφει το Χ έναρξη της Τ έναρξη της U 69

Περισσότερα προβλήματα Η T διαβάζει το X το οποίο γράφτηκε τελευταία από την U και TS(U) < TS(T). Τι θα γίνει αν μετά την ανάγνωση του Χ από την Τ, η U ακυρωθεί; είναι καλύτερο να καθυστερήσουμε την ανάγνωση από την Τ μέχρι η U να οριστικοποιηθεί ή να ακυρωθεί μπορούμε να ελέγξουμε το C(X) για να δούμε αν η U έχει οριστικοποιηθεί TS(T) < TS(U) και η U γράφει πρώτη το X. Όταν η T προσπαθήσει να γράψει, δεν κάνουμε τίποτα Κανόνας εγγραφής του Thomas: οι εγγραφές μπορούν να παραλειφθούν όταν έχει πραγματοποιηθεί ήδη μια εγγραφή με μεταγενέστερο χρόνο εγγραφής Πολιτική: όταν η T εγγράφει ένα στοιχείο X, η εγγραφή είναι δοκιμαστική (tentative write) και μπορεί να αναιρεθεί αν η Τ ματαιωθεί. Το C(X) γίνεται 0 και ο scheduler δημιουργεί ένα αντίγραφο της παλιάς τιμής του X και του προηγούμενου χρόνου εγγραφής WT(X) 70

Περισσότερα προβλήματα Dirty read U γράφει το Χ Τ διαβάζει το Χ έναρξη της U έναρξη της Τ η U ακυρώνεται U γράφει το Χ Τ γράφει το Χ έναρξη της Τ έναρξη της U T commits U aborts 71

Timestamp-based Scheduling Rules 1. If the scheduler receives a request by transaction T to read X then: a. If TS(T) >= WT(X) then i. If C(X)=1, grant the request. If TS(T) > RT(X), set RT(X):=TS(T); otherwise do not change RT(X) ii. If C(X)=0, delay T until C(X) becomes 1 or the transaction that wrote X aborts b. If TS(T) < WT(X) then abort T and restart it with a new, higher timestamp 72

Timestamp-based Scheduling Rules 2. If the scheduler receives a request by transaction T to write X then: a. If TS(T) >= RT(X) and TS(T) >= WT(X) then i. Write the new value for X ii. Set WT(X):=TS(T) iii. Set C(X):=0 b. If TS(T) >= RT(X) but TS(T) < WT(X) then there is already a later value for X. i. If C(X)=1, ignore the write by T ii. If C(X)=0, delay T 73

Timestamp-based Scheduling Rules 3. If the scheduler receives a request by transaction T to commit then, all the DB elements written by T must be found and their commit bit must be set to 1 4. If the scheduler receives a request by transaction T to abort or T must be rolled back then, any transaction waiting on X that T wrote must repeat its attempt to read or write Variations of timestamp based scheduling that use multiple versions of the DB (πολυεκδοχικά χρονόσημα) can be used when DB elements are disk blocks or pages. 74

Timestamp-based Scheduling vs Locking Timestamping outperforms locking in situations where either the majority of transactions are read-only or conflicting operations are scarce Locking performs better in high-conflict situations: Locking will delay transactions as they wait for locks; even if deadlock occurs, one of the transactions will be rolled back But, if rollbacks are frequent, even more delay will be incurred Commercial systems follow a middle-of-the-road approach: Transactions are divided in read-only and read/write Read/write are executed in 2PL; read-only are executed using timestamp-based concurrency control (με πολυεκδοχικά χρονόσημα). 75

Έλεγχος συγχρονικότητας με επικύρωση (Validation-based Concurrency Control) Another optimistic concurrency control strategy: Transactions are allowed to access data without locks Check whether transactions have executed in a serializable manner Just before a transaction starts to write values of DB elements, it goes through a validation phase where the sets of elements it has read and will write are compared with the write sets of other transactions Transactions execute in 3 phases Read Validate Write 76

Validation-based Concurrency Control Each transaction that successfully validates may be thought as executing at the moment that it validates A validation-based scheduler can use the serial order implied by the validation times of transactions in order to determine whether the transactions behaviors are consistent with it Scheduler maintains three sets: START: set of transactions that have started but not yet completed validation; START(T):time at which T started VAL: set of transactions that have been validated but not yet finished the writing phase; VAL(T):time at which T validated FIN: set of transactions that have completed phase 3; FIN(T): time at which T finished 77

Validation Rules RS(T): the set of DB elements that T reads WS(T): the set of DB elements that T writes When the validation of T is attempted: 1. Compare RS(T) with WS(U) for every U s.t. FIN(U) > START(T) and check whether RS(T) WS(U) = 2. Compare WS(T) with WS(U) for every U s.t. FIN(U) > VAL(T) check whether WS(T) WS(U) = 78

Comparison of Concurrency Control Mechanisms Storage Utilization: Locking: space required in the lock table is proportional to the number of DB elements locked Timestamps: Naive approach: store read and write times for all DB elements Timestamps earlier than that of the earliest active transaction do not matter; only the timestamps for the recently accessed elements are needed Validation: read/write sets and timestamps for each active transaction Timestamping and Validation may use a little more space than locking 79

Comparison of Concurrency Control Mechanisms Delay Effects: depend on the degree of interaction, i.e., the likelihood that a transaction will access an element that is also being accessed by another transaction Locking delays transactions but avoids rollbacks (except in deadlock situations) even when interaction is high. Timestamps and validation do not delay transactions but may cause them to rollback, which in turn results in more delays If interaction is low, neither timestamps nor validation will cause many rollbacks and may be preferable to locking If rollback becomes necessary, timestamps discover problems earlier than validation (which permits transactions to perform all work before deciding whether it needs to be rolled back) 80

View Serializability Conflict serializability guarantees serializability independently of what transactions actually do But. it is a quite strong condition on schedules of concurrent execution A weaker notion that still guarantees serializability is view serializability The main difference between conflict and view serializability appears in situations where a transaction writes a value that no other transaction reads (but possibly writes later) under view serializability such a write action can be repositioned in the schedule (might be prohibited under conflict serializability) 81

Definitions Let S 1 and S 2 be two schedules involving the same set of transactions; let T I be a hypothetical transaction that writes initial values for each DB element read by any transaction in the schedule; let T F be a hypothetical transaction that reads every element written by the transactions after the schedule ends for every R i (A), we can find the W j (A) that most closely precedes it; transaction T j is called the source of the read action S 1 and S 2 are called view equivalent if for every read action in S 1 its source is the same in S 2, and vice versa. A schedule that is view equivalent to a serial schedule is called view serializable 82

Example Consider the following schedule S: T 1 : R 1 (A) W 1 (B) T 2 : R 2 (B) W 2 (A) W 2 (B) T 3 : R 3 (A) W 3 (B) only the value of B written by T 3 is read by T F S is not conflict serializable sources for read actions: o source of R 2 (B) is T I o source of R 1 (A) and R 3 (A) is T 2 o source of R F (A) is T 2 o source of R F (B) is T 3 S is view serializable; equivalent serial schedule: (T 2, T 1, T 3 ) 83

Testing View Serializability Polygraphs: a generalization of precedence graphs a node for each transaction and additional nodes for the two hypothetical transactions an arc from Tj to T i for each action R i (X) with source Tj if Tj is the source of R i (X) and T k is another transaction that writes X, T k must appear either before Tj or after T i. This is denoted by two arcs in the graph (can choose one of the two). Special cases: if Tj is TI, then the arc from T i to T k is introduced if T i is TF, then the arc from T k to Tj is introduced 84