ТРИ ПРОБЛЕМИ ОРГАНІЗАЦІЇ паралельної роботи

Спочатку розглянемо деякі з проблем, з якими повинен допомогти впоратися будь-який механізм управління паралельним виконанням По суті, виникають три основні ситуації, в яких можуть відбуватися порушення роботи Це такі ситуації, що транзакція, будучи правильної сама по собі в тому сенсі, що визначений у главі 15, може, тим не менш, виробити неправильну відповідь, якщо в її роботу якимось чином втручаються інші транзакції При цьому необхідно враховувати важливе зауваження,

що й самі транзакції, що порушують її роботу, також розглядаються як правильні (відповідно до звичайно прийнятим допущенням), тому причиною отримання загального неправильного результату стає неконтрольоване чергування операцій двох транзакцій, які самі по собі є правильними Нижче перераховані три виникають при цьому проблеми

■ Проблема загубленого оновлення

■ Проблема залежності від незафіксованих результатів

■ Проблема аналізу несумісності

Розглянемо кожну з цих проблем по черзі

Проблема втраченого поновлення

Розглянемо ситуацію, показану на рис 161 Події, представлені на цьому малюнку, розвиваються таким чином: транзакція А виконує вибірку деякого кортежу t в момент часу tl, транзакція в виконує вибірку того ж кортежу t в момент часу t2, транзакція А оновлює кортеж в момент часу t3 (з урахуванням тих значень, які він мав під час tl), а транзакція в оновлює той же кортеж в момент часу t4 (з урахуванням тих значень, які він мав під час t2, які залишалися такими ж, як і під час tl) У момент часу t4 відбувається втрата поновлення, внесеного транзакцією А, оскільки транзакція в перезаписує його, навіть не перевіряючи

Рис 161 Приклад того, як транзакція А втрачає оновлення в момент часу t4

Примітка Тут і далі в цьому розділі прийнято угоду про використання терміна оновлення кортежу замість оновлення значення змінної кортежу

Проблема залежності від незафіксованих результатів виникає, якщо однієї транзакції дозволено виконувати вибірку (або, що ще гірше, оновлення) кортежу, який був оновлений інший транзакцією, але це оновлення ще не було зафіксовано інший транзакцією А оскільки це оновлення ще не зафіксовано, то завжди існує ймовірність, що воно так і не буде зафіксовано, а замість цього відбудеться

відкат, і в цьому випадку перша транзакція буде працювати з даними, яких більше не існує (і які в певному сенсі і не існували) Розглянемо як приклади рис 162 та 163

Рис 162 Приклад того, що транзакція A стає залежною від незафіксованого поновлення в момент часу t2

Рис 163 Приклад того, що транзакція А оновлює незафіксоване зміна в момент часу t2 і втрачає це оновлення в момент часу t3

У першому прикладі (рис 162) транзакція А отримує доступ до незафіксованим оновленню (званому також незафіксованим зміною) в момент часу t2 Потім у момент часу t3 відбувається скасування цього оновлення Таким чином, транзакція А діє на підставі помилкової передумови, що кортеж t має значення, що було нею отримано під час t2, тоді як цей кортеж фактично має те значення, яке він мав до моменту часу tl У звязку з цим транзакція А цілком може виробити неправильні результати До речі, слід зазначити, що відкат транзакції в цілком може відбутися не через помилку в в наприклад, він може статися через аварійної зупинки системи (А якщо транзакція А до цього часу вже буде завершена, то такий останов не спричинить за собою виконання відкоту також і для А)

У другому прикладі (рис 163) події розвиваються за ще більш гіршого сценарію Транзакція А стає не тільки залежною від незафіксованого зміни в момент часу t2, а й фактично втрачає своє оновлення під час t3, оскільки відкат у момент часу t3 викликає відновлення кортежу t до того значення, яке він мав до моменту часу tl, тобто це ще один варіант проблеми втраченого оновлення

Проблема аналізу несумісності

Розглянемо рис 164, де показані дві транзакції, А і в, які оперують з кортежами деякого рахунку (ACCount – АСС) Транзакція А підраховує залишки на рахунках, а транзакція У переводить суму 10 з рахунку 3 на рахунок 1 Очевидно, що результат, вироблений транзакцією А, – 110, є неправильним якби в ході свого подальшого виконання транзакція А знову записала цей результат в базу даних, то фактично залишила б базу даних в суперечливому состояніі1 По суті, транзакція А виявила несумісне стан бази даних і тому виконала аналіз несумісності Зверніть увагу на відмінність між цим прикладом і попереднім: в даному випадку не виникає проблема залежності транзакції А від незафіксованого зміни, оскільки в зафіксувала всі свої оновлення ще до того, як А прочитала

значення АСС 3

Примітка До речі, слід зазначити, що замість терміна аналіз несумісності слід було б застосовувати аналіз неправильності Але ми за традицією дотримуємося колишнього терміна

Більш докладний опис розглянутих проблем

Примітка Цей підрозділ при першому читанні можна пропустити

У даному підрозділі описані вище проблеми розглядаються трохи більш докладно Очевидно, що з точки зору організації паралельної роботи найбільший інтерес представляють такі операції, як вибірка інформації з бази даних і оновлення бази даних іншими словами, будь-яка транзакція може розглядатися як що складається з послідовності тільки зазначених операцій (безумовно, якщо не враховувати такі необхідні операції, як BEGIN TRANSACTION І COMMIT АБО ROLLBACK) Надалі ці операції будуть скорочено позначатися, відповідно, як R (читання) і w (запис) У такому випадку стає ясно, що якщо А і в – паралельно виконувані транзакції, то проблеми можуть виникнути, якщо в ході виконання А і B потрібно прочитати або записати один і той же обєкт бази даних, наприклад, кортеж t При цьому виникають чотири можливі конфліктні ситуації, які описані нижче

■ Конфлікт типу RR І в транзакції А, і в транзакції в необхідно виконати читання кортежу t Операції читання не можуть порушувати роботу один одного, тому в даній ситуації проблема не виникає

■ Конфлікт типу RW У транзакції А виконується читання кортежу t, а потім у тран ЗАКЦ в виникає необхідність записати кортеж t Якщо транзакції в буде дозволено виконати цю запис, то (як показано на рис 164) може виникнути проблема аналізу несумісності, тому можна стверджувати, що проблема аналізу несумісності викликана конфліктами типу RW

Примітка Якщо транзакція В виконує свою операцію запису, а потім транзакція А знову зчитує значення t, то остання виявляє значення, відмінне

1 Якщо ми допускаємо таку можливість (тобто запис вказаного результату назад в базу даних), то, природно, повинні також допустити, що не задані обмеження цілісності, які виключили б можливість такого запису

від того, що було прочитано раніше такий збіг обставин прийнято позначати (не зовсім точно) як неповторяющимися читання, тому проблема неповторюваного читання також викликається конфліктом типу RW

■&nbsp Конфлікт типу WR У транзакції А виконується запис кортежу t, а потім у транзакції в виникає необхідність прочитати t Якщо транзакції в буде дозволено виконати цю операцію читання, то (як показано на рис 162, з урахуванням того, що транзакції А І В помінялися ролями) може виникнути проблема залежності від незафіксованих оновлень таким чином, можна стверджувати, що проблема залежності від незафіксованих оновлень викликається конфліктами типу WR

Примітка Читання в транзакції в, якщо воно буде дозволено, називається брудним читанням (dirty read)

Рис 164 Приклад того, що транзакція А виконує аналіз несумісності

■&nbsp Конфлікт типу WW У транзакції А виконується запис кортежу t, а потім необхідність виконати запис кортежу t виникає в транзакції в Якщо транзакції В буде дозволено виконати цю запис, то (як показано на рис 161, а також на рис 163) може виникнути проблема втраченого оновлення таким чином, можна стверджувати, що проблема втраченого поновлення викликана конфліктами типу WW

Примітка Запис у транзакції в, якщо вона буде дозволена, називається брудної записом (dirty write)

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*