1. 6.4 Транзакції і паралельна робота Будь-яка система в бізнесі представляє безліч дійових осіб - акторів...
2. Залежність від незафіксованих результатів (читання "брудних" даних)
3. Феномен "є повторюваною читання"
4. Феномен появи записів "фантомів"
5. 6.4.2 Рівні ізольованості користувачів

6.4 Транзакції і паралельна робота

Будь-яка система в бізнесі представляє безліч дійових осіб - акторів - працюють одночасно і організовано. Актором може бути людина, програма або машина. Інформаційна система повинна якось відображати цю многоакторность. Звичайно, в ній самій можуть з'явитися паралельні процеси, які не мають прямих аналогів в бізнесі.

У цьому розділі будуть розглянуті проблеми, що виникають при паралельній роботі транзакцій. Відповідно до традиції будемо називати ці проблеми феноменами. На основі феноменів задамо рівні ізольованості транзакцій. У визначеннях ізольованості буде використаний стандарт версії SQL-92 мови SQL, але знання SQL і, тим більше, стандарту для освоєння матеріалу не потрібно.

У заключній частині розділу розглянемо блокування ресурсів і ефекти, що виникають при блокуванні.

6.4.1 Феномени

Феномен "Втрачені зміни"

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

Приклад (таблиці 6.4 і ( 6.5 ): На рахунок Acc з початковим сальдо 100, зараховують першої транзакцією 20 руб., А другий 100 руб. Якщо перша транзакція записує змінені дані в базу і завершується після того, як друга транзакція їх прочитала, але до того, як вона їх записала, то зміни, внесені першої транзакцією, губляться.

Таблиця 6.4. Приклад феномена Феномен "Втрачені зміни". Транзакції Транзакція 1 Час Транзакція 2 Початок ТР1 Читання X = Acc to Початок ТР2 ti Читання X = Acc t2 Зарахування X = X + 100 Зарахування X = X + 20 t3 Запис в базу Acc = X t4 COMMIT Кінець ТР1 t5 Запис в базу Acc = X COMMIT Кінець ТР2 Таблиця 6.5. Приклад феномена "Втрачені зміни". USER> TStart USER> Set Х = ^ Асс, t = Q USER> Set Х = Х + 20, t = 3 USER> Set ^ Асс = Х, t = 4 USER> TCommit USER> USER> TStart USER> Set Х = ^ Асс, t = 1 USER> Set X = X + 100, t = 2 USER> Set ^ Acc = X, t = 5 U5ER> TComoit USER> Write ^ Acc 2 00 USER> |

Початкове значення ^ Acc = 100. TSTART - початок транзакції, TCOMMIT - її успішне завершення. Мінлива t, як і раніше, використана замість коментаря для завдання позначки черговості виконання команд, що відповідає моментам часу .

Залежність від незафіксованих результатів (читання "брудних" даних)

Феномен виникає, коли читаються дані незавершеної транзакції, які згодом відкочуються. Початкове значення Acc в прикладі дорівнює 100 (таблиці 6.6 і 6.7 ).

Таблиця 6.6. Приклад феномена "Читання брудних даних". Транзакції Транзакція 1 Час Транзакція 2 Початок ТР1 Зміна Acc = Acc + 20 t1 Початок ТР2 t2 Читання і зміна X = Acc + 50 ROLLBACK-повернення до Acc = 100 tз Кінець ТР1 t4 Acc = X Кінець ТР2. Значення Acc НЕ 150, а 170 Таблиця 6.7. Приклад феномена "Читання брудних даних" USER> TStart USER> Set ^ Acc = ^ Acc + 20, t = 1 USER> TRollback USER> Sett = 3 Rollback Write ^ Acc 100 USER> USER> TStart USER> SX = ^ Acc + 50 , t = 2 USER> Set ^ Acc = X, t = 4 USER> TCommit USER> Set t = 5 USER> Write ^ Acc 170

Феномен "є повторюваною читання"

Розберіть самі наведений нижче приклад (таблиці 6.8 і 6.9 ).

Таблиця 6.8. Приклад феномена "є повторюваною читання". Транзакції Транзакція 1 Час Транзакція 2 Початок ТР2 t1 Читання Acc (Acc = 100) Початок ТР1 Зміна Acc = 300 t2 Перевірка Acc <200 - Так t3 Читання Acc (Acc = 300) Перевірка Acc <200 - Ні Таблиця 6.9. Приклад феномена "є повторюваною читання" USER> TStart U5ER> Set t = 2, ^ Acc = 300 USER> USER> TStart USER <Set t = l USER> If ^ Acc <200 Write "Так" Так USER> Set t = 3U SER > If ^ Acc <200 Write "Так" USER> |

Феномен появи записів "фантомів"

Нижче ми вивчимо блокування, тобто захист від спроб спільного використання записів. За рахунок блокувань на рівні рядків перераховані вище три феномена можуть бути виключені. Але залишиться ще одна проблема.

Нехай транзакція ТР1 вибирає групу рядків з таблиці Т, які відповідають умові У1. Потім транзакція ТР2 вставляє в Т ще один рядок, що задовольняє умові У1. При повторній вибірці рядків транзакцією ТР1, до отриманого в попередній вибірці набору додається ще один рядок, звана фантомом, примарою.

6.4.2 Рівні ізольованості користувачів

Стандарт SQL-92, грунтуючись на перерахованих феномени, визначає чотири рівні ізольованості:

1. Read uncommitted. Читання незафіксованих змін. Найнижчий рівень ізоляції. Сприймаються як остаточні, так і проміжні результати інших транзакцій. СУБД запобігає тільки проблему втрачених змін.
2. Read committed. Читання зафіксованих змін. Рівень ізоляції вище, ніж у read uncommited. Транзакція не має доступу до проміжних результатів інших транзакцій. Але остаточні результати інших транзакцій, що завершилися під час виконання нашої транзакції, можуть бути доступні. можливе отримання
3. різних результатів при повторі запиту до і після фіксації інший транзакції, що змінює дані. Можливі фантоми.
4. Repeatable read. Повторюване читання. Рівень ізоляції вище, ніж у read commited. Транзакція не має доступу до проміжних або остаточними результатами інших транзакцій. Вставки записів призводять до появи фантомів.
5. Serializable. Серіалізуемость. Найвищий рівень ізоляції. Результат паралельного виконання транзакцій буде точно таким же як при послідовному їх виконанні. Всі перераховані вище феномени відсутні, але паралельне виконання транзакцій, які працюють з одними ресурсами неможливо.

Дані за рівнями ізольованості зведені в таблицю 6.10 . Знак "+" в ній означає наявність феномена, а знак "-" - його відсутність.

Таблиця 6.10. Рівні ізольованості і відсутність феноменів Рівень Втрачені "Брудна" є повторюваною Фантоми ізоляції зміни читання читання Serializable + + + + Repeatable read + + + - Read commited + + - - Read uncommited + - - -

Так навіщо потрібні "погані" види транзакцій, і особливо, Read uncommited?

Відповідь проста. З одного боку, чим вище рівень ізоляції, тим менше шансів на паралельну роботу транзакцій. З іншого боку, повна ізоляція не завжди корисна.

Приклад: Бібліотекарі регулярно працюють з каталогом, відкриваючи транзакції для звірки та зміни каталогу. Ці роботи можуть тривати годинами. Що Ви вважаєте за краще, чекати появи виправленого каталогу, або переглядати його в будь-який момент часу, може бути, іноді отримуючи неправильні дані?

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

Як забезпечити правильну роботу транзакцій, які звертаються до одних і тих же ресурсів?

Два основних способи:

• блокування "загальних" ресурсів;
• надання транзакціях, конкуруючим за ресурси, різних примірників даних.