1. בקרת בו זמניות (concurrency control)
טרנזקציה (transaction): תוכנית הניגשת לנתונים ו(אולי) מעדכנת אותם.
partially
committed
committed
דיאגרמת מצבים
active
failed
aborted

2. דרישות של מודל הטרנזקציה
Atomicity
Consistency
Isolation
Durability
For each transaction:
Atomicity: either all or none of its operations are properly reflected on the database
Consistency: the execution in isolation (namely with no other trasactions executing concurrently) preserves the consistency fo rthe database
Isolation: Even of multiple transactions execute concurrently – for each pair of transactios Ti Tj it appears to Ti that either Tj finished its execution before Ti started or Tj finished execution after Ti finished.
Durability: After a transaction completed successfully, the changes it made to the database persist – even if there are system failures

3. תזמון (schedule)
תזמון (schedule): תזמון של קבוצת טרנזקציות הוא רצף של פעולות, הכולל את כל הפעולות השייכות לקבוצת הטרנזקציות והשומר על הסדר שבו מופיעות הפעולות בכל אחת מהטרנזקציות.
תזמון סדרתי (serial schedule): תזמון בו הפעולות השייכות לכל אחת מהטרנזקציות מופיעות ברצף, כלומר לא משולבות ביניהן פעולות של טרנזקציות אחרות.
תזמון לא סדרתי (nonserial schedule): תזמון בו הפעולות השייכות לקבוצת טרנזקציות משולבות זו בזו.

4. תזמונים, המשך T0 – העבר 50 מחשבון A ל-B, T1 – העבר 10% מחשבון A ל-.B
תזמון סדרתיS1 -
תזמון סדרתיS2 -
ערכים התחלתיים
A = 1000, B = 2000
T T1
T T1
read(A)
A = A-50
write(A)
read(B)
B = B+50
write(B)
tmp = A*0.1
A = A-tmp
B = B+tmp
read(A)
tmp = A*0.1
A = A-tmp
write(A)
read(B)
B = B+tmp
A = A-50
B = B+50
write(B)
ערכים סופיים A = 850, B = 2150
ערכים סופייםA = 855 B = 2145

5. תזמונים, המשך T0 – העבר 50 מחשבון A ל-B, T1 – העבר 10% מחשבון A ל-.B
תזמון סדרתיS1 -
תזמון בו-זמניS3 -
ערכים התחלתיים
A = 1000, B = 2000
T T1
T T1
read(A)
A = A-50
write(A)
read(B)
B = B+50
write(B)
tmp = A*0.1
A = A-tmp
B = B+tmp
read(A)
A = A-50
write(A)
tmp = A*0.1
A = A-tmp
read(B)
B = B+50
write(B)
B = B+tmp
ערכים סופיים A = 855, B = 2145
ערכים סופייםA = 855 B = 2145

6. תזמונים, המשך T0 – העבר 50 מחשבון A ל-B, T1 – העבר 10% מחשבון A ל-.B
תזמון סדרתיS1 -
תזמון בו-זמני לא שקולS4 -
ערכים התחלתיים
A = 1000, B = 2000
read(A)
A = A-50
write(A)
read(B)
B = B+50
write(B)
T T1
T T1
read(A)
A = A-50
write(A)
read(B)
B = B+50
write(B)
read(A)
tmp = A*0.1
A = A-tmp
write(A)
read(B)
B = B+tmp
write(B)
read(A)
tmp = A*0.1
A = A-tmp
write(A)
read(B)
B = B+tmp
write(B)
ערכים סופייםA = 855 B = 2145
ערכים סופיים A = 950, B = 2150

7. conflict serializability
פעולות מתנגשות (conflicting opertaions) :שתי פעולות עוקבות השייכות לטרנזקציות שונות, הן פעולות מתנגשות אם הן מתייחסות לאותו פריט מידע ואם לפחות אחת מהן היא פעולת כתיבה.
שקילות קונפליקט (conflict equivalence) : שני תזמונים S ו `S הם שקולי קונפליקט ( conflict equivalent ) אם ניתן לעבור מתזמון S לתזמון `S על ידי סדרה של החלפות של פעולות שאינן מתנגשות.
conflict serializable schedule תזמון הוא conflict serializable אם הוא שקול קונפליקט לתזמון סדרתי כלשהו.

8. testing for conflict serializability
בדיקת conflict serializability: גרף קדימויות (precedence graph).
יהי S תזמון. גרף קדימויות של S מורכב מקבוצה V של קדקודים וקבוצה E של קשתות. לכל טרנזקציה מS מתאים קודקוד ב V. הקבוצה E כוללת קשת TiTj אם קיים פריט מידע Q כך שמתקיים אחד מהתנאים:
Ti מבצעת (write(Q לפני ש Tj מבצעת (read(Q.
Ti מבצעת (read(Q לפני ש Tj מבצעת (write(Q.
Ti מבצעת (write(Q לפני ש Tj מבצעת (write(Q.
אם הגרף כולל מעגל מכוון - התזמון אינו conflict serializable. אחרת התזמון conflict serializable

9. view serializability
שקילות תצפית (view equivalence) : שני תזמונים S ו `S הם view equivalent אם הם מורכבים מאותה קבוצה של טרנזקציות, ואם לכל פריט מידע Q מתקיימים שלושת התנאים הבאים:
אם בתזמון S טרנזקציה Ti קוראת את ערכו ההתחלתי של Q, אזי בתזמון `S טרנזקציה Ti קוראת את ערכו ההתחלתי של Q .
אם בתזמון S טרנזקציה Ti קוראת את ערכו של Q, וערך זה נוצר על ידי טרנזקציה Tj אזי בתזמון `S טרנזקציה Ti קוראת את הערך של Q שנוצר על ידי טרנזקציה Tj.
אם בתזמון S הטרנזקציה Ti כותבת את ערכו הסופי של Q, אזי בתזמון `S הטרנזקציה Ti כותבת את ערכו הסופי של Q .
בר-סדרתיות תצפית (view serializable): תזמון הוא view serializable אם הוא שקול-תצפית לתזמון סדרתי כלשהו.

10. הערות
סיבוכיות הבדיקה האם תזמון בר-סידור קונפליקטי: O(n2) (בדיקת מעגלים בגרף); סיבוכיות הבדיקה האם תזמון בר-סידור תצפיתי: NP-Complete.
כל תזמון שהוא בר-סידור קונפליקטי הוא גם בר-סידור תצפיתי (אך לא ההיפך).
לדוגמא:
T1 T2 T3
read(Q)
write(Q)

11. פרוטוקולים של בקרת בו זמניות
פרוטוקולי נעילה
פרוטוקולי תג זמן
פרוטוקולים אופטימיים

12. פרוטוקולים מבוססי נעילה
נעילה משותפת (shared lock): אם טרנזקציה Ti קיבלה נעילה משותפת (המסומנת ב S-lock) על פריט מידע Q אזי Ti רשאית לקרוא פריט זה אך לא לכתוב אותו.
נעילה בלעדית (exclusive lock): אם טרנזקציה Ti קיבלה נעילה בלעדית (המסומנת ב X-lock) על פריט מידע Q אזי Ti רשאית לקרוא פריט זה ולכתוב אותו.

13. כללי השימוש בנעילות
לפני הגישה לפריט מידע כלשהו טרנזקציה חייבת לנעול אותו, על ידי בקשת נעילה משותפת לגישה של קריאה בלבד ונעילה בלעדית לגישת קריאה וכתיבה.
אם פריט המידע אינו נעול על ידי טרנזקציה אחרת, הנעילה תאושר.
אם פריט המידע נעול, הDBMS קובע מתי הבקשה תואמת את הנעילה הקיימת. אם הבקשה היא לנעילה משותפת של פריט שקיימת עליו כבר נעילה משותפת, הנעילה תאושר; בכל מקרה אחר הטרנזקציה המבקשת חייבת להמתין (wait) עד שהנעילה הקיימת תשוחרר.
טרנזקציה ממשיכה להחזיק בנעילה עד אשר היא משחררת אותה באופן מפורש במהלך הביצוע או כאשר היא מסיימת פעולתה. תוצאות פעולת כתיבה הופכות זמינות לטרנזקציות אחרות רק כאשר משתחררת נעילת הכתיבה.

14. כללי השימוש בנעילות – דוגמא 1
Concurrency-control manager T0 T1
Xlock(A)
read(A)
write(A)
unlock(A)
Xlock(B)
read(B)
write(B)
unlock(B)
Xlock(A)
read(A)
write(A)
unlock(A)
Xlock(B)
read(B)
write(B)
unlock(B)
grant-X(A,T0)
grant-X(A,T1)
grant-X(B,T0)
grant-X(B,T1) T2

15. כללי השימוש בנעילות – דוגמא 2
Concurrency-control manager T0 T2
Xlock(A)
read(A)
write(A)
unlock(A)
Xlock(B)
read(B)
write(B)
unlock(B)
Slock(A)
read(A)
unlock(A)
Slock (B)
read(B)
unlock(B)
Display(A+B)
grant-X(A,T0)
grant-S(A,T2)
grant-S(B,T2)
grant-X(B,T0)

16. פרוטוקול “נעילה דו-פאזית” (two phase locking)
פאזת גדילה (growing phase) הטרנזקציה רשאית לבקש נעילות אך לא לשחרר נעילות.
פאזת הצטמקות (shrinking phase): הטרנזקציה רשאית לשחרר נעילות אך לא לבקש נעילות.
וריאציות של 2PL:
בסיסי (מה שתואר לעיל).
Conservative 2PL או static 2PL : הטרנזקציה נדרשת להכריז מראש על כל פריטי המידע אליהם ניגשת (read set, write set) . נעלת הפריטים נעשית באופן אטומי. הטרנזקציה רשאית לשחרר נעילות בכל שלב. (מימוש מסובך – לא פשוט להגדיר מראש את קבוצות הפריטים). ייתרון: נקי מנעילות מוות.
Strict 2PL הטרנזקציה אינה משחררת נעילות כתיבה אלא רק לאחר שלב ה commit או abort. אינו נקי מנעילות מוות. קל למימוש, ומייצר תזמונים recoverable.
rigorous 2PL: דומה ל strict 2PL אך הטרנזקציה אינה משחררת נעילות כלל אלא רק לאחר שלב ה commit או abort (גם לא נעילות משותפות). קל יותר למימוש.
כל התזמונים החוקיים תחת 2PL הם serializable.
הפרוטוקול אינו נקי מנעילות מוות (deadlock).

17. פרוטוקולי נעילה מבוססי גרפים
מגדירים סדר חלקי  על קבוצת פריטי המידע {D = {d1, d2, ...dn
בבסיס הנתונים . אם di dj אזי כל טרנזקציה הניגשת לשני פריטי המידע di ו dj חייבת לגשת ל di לפני שניגשת ל dj .
את הסדר החלקי המושרה על D ניתן לייצג כגרף מכוון אציקלי (acyclic), הנקרא גרף בסיס הנתונים.

18. פרוטוקול עץ (tree protocol)
נעזר בנעילות בלעדיות (xlock) בלבד.
טרנזקציה T רשאית לנעול פריט מידע בהתאם לכללים הבאים:
הנעילה הראשונה של T עשויה להיות על פריט מידע כלשהו.
בהמשך, פריט מידע Q עשוי להינעל ע”י T רק אם ההורה של Q נעול ע”י T.
T רשאית לשחרר נעילות בכל זמן שהוא.
T אינה רשאית לנעול פריט מידע שננעל ושוחרר על ידיה.
כל התזמונים החוקיים תחת פרוטוקול העץ הם conflict serializable.
הפרוטוקול נקי מנעילות-מוות.

19. פרוטוקול עץ - דוגמה T1 T2 T3 A B C D E F G H I J xlock(B) xlock(D)
פרוטוקול עץ - דוגמה
T1 T2 T3
xlock(B)
xlock(D)
xlock(H)
unlock(D)
xlock(E)
unlock(E)
unlock(B) xlock(B)
unlock(H)
xlock(G)
unlock(D) unlock(E) unlock(B)
unlock(G) A B C D E F G H I J

20. פרוטוקול תג זמן (timestamp protocol)
כל טרנזקציה Ti מקבלת חותמת זמן (או 'תג זמן') TS(Ti) ייחודית וקבועה על ידי ה DBMS המעידה על המועד היחסי של תחילת הטרנזקציה.
בנוסף כל פריט מידע מקבל שתי חותמות זמן:
W-timestamp המציינת את הערך המירבי של חותמות הזמן של טרנזקציות שכתבו בהצלחה את פריט המידע. (חותמת הזמן של הטרנזקציה הצעירה ביותר שכתבה את פריט המידע)
R-timestamp המציינת את הערך המירבי של חותמות הזמן של טרנזקציות שקראו את פריט המידע. (חותמת הזמן של הטרנזקציה הצעירה ביותר שקראה את פריט המידע)

21. חותמות זמן- דוגמא T1 T2 T3 נניח שחותמות הזמן של הטרנזקציות הן:
read(A)
write(A)
write(B)
read(B)
read(C)
write (A)
write(C)
נניח שחותמות הזמן של הטרנזקציות הן:
TS(T1) = 1, TS(T2) = 2, TS(T3) = 3 . מה יהיו חותמות הזמן של A, B, C?

22. timestamp ordering protocol
אם טרנזקציה Ti מבצעת (read(Q:
אם (TS(Ti)<W-timestamp(Q פעולת הקריאה נדחית ו Ti מגולגלת אחורנית.
אם (TS(Ti)>=W-timestamp(Q פעולת הקריאה מתבצעת; יש לעדכן (אולי) את ( R-timestamp(Q.
אם טרנזקציה Ti מבצעת (write(Q:
אם (TS(Ti)<R-timestamp(Q פעולת הכתיבה נדחית ו Ti מגולגלת אחורנית.
אם (TS(Ti)<W-timestamp(Q פעולת הכתיבה נדחית ו Ti מגולגלת אחורנית.
אחרת פעולת הכתיבה מתבצעת; יש לעדכן את ( W-timestamp(Q.
אם טרנזקציה Ti מגולגלת אחורנית כתוצאה מפעולת read או write היא מקבלת חותמת זמן חדשה ומותחלת מחדש.
תכונות הפרוטוקול: conflict serializable. (לא סתם, אלא שקול קונפליקט לתזמון הסדרתי לפי סדר חותמות הזמן) נקי נעילות מוות. אבל: מייצר תזמונים שאינם recoverable.
וריאציה: strict TO : טרנזקציה T המבצעת read(Q) או write(Q) כך ש TS(T) <WTS(Q) מבצעת פעולת קריאה או כתיבה דחויה, הדחייה היא עד אשר הטרנזקציה T’ שכתבה את הערך של Q (כך ש TS(T’) = WTS(Q)) תעבור למצב commit או abort.
לשם כך יש לחקות נעילה של פריט Q שנכתב ע"י T’ עד שהיא מסיימת (commit/abort). האלגוריתם אינו גורם לנעילות מוות כיוון שT מחכה רק זמן סופי, עד שהטרנזקציה הזקנה יותר T’ מסיימת.

23. Thomas’ write rule וריאציה על פרוטוקול חותמות הזמן הבסיסי:
אם טרנזקציה Ti מבצעת (read(Q:
הכללים זהים לאלה של פרוטוקול תגי-הזמן הבסיסי.
אם טרנזקציה Ti מבצעת (write(Q:
אם (TS(Ti)<R-timestamp(Q פעולת הכתיבה נדחית ו Ti מגולגלת אחורנית.
אם (TS(Ti)<W-timestamp(Q מתעלמים מפעולת הכתיבה.
אחרת פעולת הכתיבה מתבצעת; יש לעדכן את ( W-timestamp(Q.
השימוש בThomas’ write rule מאפשר יצירת תזמונים שאינם אפשריים בפרוטוקול נעילה כלשהו.

24. שיטות אופטימיות (optimistic / validation methods)
אין כל בדיקה של serializability בזמן ביצוע טרנזקציה, אלא רק לאחר סיומה.
שלושה שלבים:
read phase: הטרנזקציה קוראת נתונים מבסיס הנתונים, אך עדכונים נעשים לעותק לוקלי של פריטי המידע.
validation phase: נערכת בדיקה להבטיח כי אין פגיעה ב serializability אם העדכונים יבוצעו על בסיס הנתונים.
write phase: אם בדיקת התקינות בשלב הקודם הצליחה העדכונים נעשים על בסיס הנתונים; אחרת, כל העדכונים מבוטלים והטרנזקציה מופעלת מחדש.

25. Validation phase TS(Ti) = validation (Ti) TS(Tj) < TS(Ti)
(start(Ti - מציין תחילת הטרנזקציה Ti
(validation(Ti - מציין את סיום שלב הקריאה (read phase) ותחילת שלב האימות (validation phase) של Ti
(finish(Ti - מציין סיום שלב הכתיבה של Ti
פרוטוקול חותמת-הזמן מתבצע עם חותמת הזמן
מבחן ה validation לגבי טרנזקציה Ti דורש כי כל טרנזקציה Tj בעלת חותמת זמן קטנה יותר, , תקיים אחד משני התנאים:
finish(Tj) < start(Ti)
קבוצת פריטי המידע ש Tj כותבת זרה לקבוצת פריטי המידע ש Ti קוראת, וTj מסיימת את שלב הכתיבה לפני ש Ti מתחילה את שלב האימות.
אם Tj נכשלה בשלב הוולידציה שלה - ניתן להתעלם ממנה במבחן הvalidation
TS(Ti) = validation (Ti)
TS(Tj) < TS(Ti)
הסיבה שבוחרים validation(Ti כתג הזמן של הטרנזקציה ולא את start(Ti : אחרת טרנזקציות מהירות היו נתקעות מאחורי טרנזקציות ממושכות שהחלו קודם.
מבחן האימות: (מסתכלים על כל הטרנזקציות Tj שיותר ותיקות מ Ti)
אם Tjמסיימת את הביצוע לפני ש Ti מתחילה, סדר הטרנזקציות נשמר.
התנאי start(Ti) < finish(Tj) < validation(Ti) מבטיח כי הכתיבות והקריאות של הטרנזקציות אינן חופפות. כתיבות של Tj אינן משפיעות על קריאות של Ti (ראה התנאי על פריטי מידע) ו Ti אינה יכולה להשפיע על קריאות של Tj (בכל מקרה, גם אם Ti כותבת פריטים שTj קוראת). , ולכן serializability נשמרת.
להדגים עם התזמון הבא (הדוג’בספר לא תקינה!!!) וכן עם תזמון conflict serializable
t T1 T2 T3
0 start
1 read(Q)
2 start
3 write(Q)
4 write(Q)
5 validation
6 start 7
8 finish
9 validation
10 write(Q)
11 finish
12 validation
13 finish

26. Multiple granularity
פרוטוקולים המאפשרים לנעול בסיס נתונים ברמות שונות של גרנולריות.
למשל, ברמה של בסיס הנתונים, שטח, קובץ, רשומה. DB A1 A2 F1 F2 F3
בכל הגישות שתוארו עד כה, התייחסנו לכל פריט מידע כיחידה שעליה צריכה להתבצע סינכרוניזציה. עיתים יעיל יותר לקבץ כמה פריטי מידע ליחידה אחת. למשל, במקרה שמשתמשים בנעילות וטרנזקציה צריכה לגשת לכל בה”נ - היא צריכה לנעול כל אחד מהפריטים בבה”נ.
מגדירים הירארכיה של גרנולריות. את ההירארכיה ניתן לייצג כעץ.
להבדיל מפרוטוקול העץ, ששם כל צומת מייצגת פריט מידע בודד!!!.
כל צומת של העץ ניתנת לנעילה. כמו בנעילה דו פאזית, נשתמש בנעילה בלעדית ובנעילה משותפת. באופן כזה, כאשר טרנזקציה נועלת צומת מסוים ,כל הצאצאים של הצומת ננעלים באותו סוג של נעילה.
למשל, בנעילה מפורשת של F3 בנעילה בלעדית, כל הרשומות R6 עד R9 ננעלות מאופן סתום בנעילה בלעדית.
מובן שאם טרנזקציה מנסה לנעול צומת מסוים בנעילה כלשהי, הנעילה תאושר רק אם כל הצאצאים שלה אינם נעולים או אם כולם נעולים באופן קומפטבילי.
למשל, אם טרנזקציה T המבקשת נעילה בלעדית על DB אך טרנזקציה אחרת מחזיקה נעילה משותפת על חלק כלשהו של העץ, למשל F2 , הנעילה לא תאושר ו T תאלץ להמתין.
כיצד קובעים אם כן מתי בקשת נעילה כזו תאושר? סריקת כל תת העץ (במקרה זה כל העץ כולו) הינה דרך מאוד לא יעילה. במקום זה, מגדירים סוגי נעילה נוספים הנקראים intention locks . אם צומת נעול ב intention lock קיימת נעילה מפורשת של צומת כלשהו ברמה נמוכה יותר. וכו’ R1 R2 R3 R4 R5 R6 R7 R8 R9
הירארכיה של גרנולריות

27. Intention Locks
כאשר צומת ננעל בנעילה בלעדית או משותפת, נעילה מתאימה מתבצעת על כל הצאצאים בעץ. intention locks מושמות על כל ההורים של הצומת, לפני שהוא ננעל מפורשות.
טרנזקציה המבקשת לנעול צומת כלשהו Q, עוברת את הנתיב משורש העץ עד Q, ותוך כדי כך, נועלת ב intention locks את הצמתים על הנתיב.
סוגי intention locks
intention shared (IS)
intention exclusive (IX)
כיצד קובעים אם כן מתי בקשת נעילה כזו תאושר? סריקת כל תת העץ (במקרה זה כל העץ כולו) הינה דרך מאוד לא יעילה. במקום זה, מגדירים סוגי נעילה נוספים הנקראים intention locks . אם צומת נעול ב intention lock קיימת נעילה מפורשת של צומת כלשהו ברמה נמוכה יותר. וכו’
IS מצביעה כי נעילה משותפת עומדת להתבקש על צומת צאצא כלשהו
IX - מצביעה כי נעילה בלעדית עומדת להתבקש על צומת צאצא כלשהו
SIX - קיימת נעילה משותפת על הצומת הנוכחי, אך נעילה בלעדית עומדת להתבקש על צומת צאצא כלשהו

28. Compatibility Matrix X S IX IS
false
true

29. MGL – Multiple Granularity Locking
נעילות שאינן תואמות את מטריצת הקומפטיביליות אינן מאושרות.
בכל סוג נעילה, שורש העץ חייב להינעל ראשון (בכל סוג נעילה).
צומת N יכול להינעל ע"י טרנזקציה T בנעילה מסוג S או IS רק אם parent(N) נעול ע"י T בנעילת IS או IX.
צומת N יכול להינעל ע"י טרנזקציה T בנעילה מסוג X או IX רק אם parent(N) נעול ע"י T בנעילת IX.
טרנזקציה T יכולה לנעול צומת רק אם היא עדיין לא שחררה אף צומת (2PL).
טרנזקציה T יכולה לשחרר צומת N רק אם אף אחד מ descendants(N) אינו נעול כעת ע"י T.
דוגמא:

30. Isolation level in SQL
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE | READ COMMITED | REPEATABLE READ | READ UNCOMITTED
Level
Dirty Read
NonRepeatable Read
Phantom Read
Read Uncommitted
Yes
Read Committed No
Repeatable Read
Serializable
dirty read: A transaction reads data written by a concurrent uncommitted transaction.
nonrepeatable read: A transaction re-reads data it has previously read and finds that data has been modified by another transaction (that committed since the initial read).
phantom read: A transaction re-executes a query returning a set of rows that satisfy a search condition and finds that the set of rows satisfying the condition has changed due to another recently-committed transaction.
Read Uncommitted: reading a value that an uncommitted transaction wrote; transaction do not issue locking for reads, so no waits even if there are xlocks on data item used by transaction.
Read Committed: transaction reads only committed data. Still, when reading again a data item, it may find it has changed. Also, new rows might appear that meet the criteria of the original query. Rows that appear in this way are called phantoms. (this is usually the default).
Repeatable Read: if transaction issues the same query twice, it is ensured to get identical results. However, since only records that where retrieved by the first query are ‘protected’ phantoms are still possible.
Serializable: enforces stringent locking. This is NOT the term we used previously – serializable.