користувачів.
При дотриманні обов'язкової вимоги підтримки цілісності бази даних можливі наступні рівні ізольованості транзакцій:
В· Перший рівень - відсутність втрачених змін. Розглянемо наступний сценарій спільного виконання двох транзакцій. Транзакція 1 змінює об'єкт бази даних A. До завершення транзакції 1 транзакція 2 також змінює об'єкт A. Транзакція 2 завершується оператором ROLLBACK (наприклад, з причини порушення обмежень цілісності). Тоді при повторному читанні об'єкта A транзакція 1 цієї статті не бачить змін цього об'єкту, вироблених раніше. Така ситуація називається ситуацією втрачених змін. Природно, вона суперечить вимозі ізольованості користувачів. Щоб уникнути такої ситуації в транзакції 1 потрібно, щоб до завершення транзакції 1 ніяка інша транзакція не могла змінювати об'єкт A. Відсутність втрачених змін є мінімальним вимогою до СУБД за частиною синхронізації паралельно виконуваних транзакцій. p> В· Другий рівень - відсутність читання "брудних даних". Розглянемо наступний сценарій спільного виконання транзакцій 1 і 2. Транзакція 1 змінює об'єкт бази даних A. Паралельно з цим транзакція 2 читає об'єкт A. Оскільки операція зміни ще не завершена, транзакція 2 бачить неузгоджені "Брудні" дані (зокрема, операція транзакції 1 може бути відвернута при перевірці негайно перевіряється обмеження цілісності). Це теж не відповідає вимозі ізольованості користувачів (кожен користувач починає свою транзакцію при узгодженому стані бази даних і в праві чекати бачити узгоджені дані). Щоб уникнути ситуації читання "Брудних" даних, до завершення транзакції 1, яка змінила об'єкт A, ніяка інша транзакція не повинна читати об'єкт A (мінімальною вимогою є блокування читання об'єкта A до завершення операції його зміни в транзакції 1). p> В· Третій рівень - відсутність неповторюваних читань. Розглянемо наступний сценарій. Транзакція 1 читає об'єкт бази даних A. До завершення транзакції 1 транзакція 2 змінює об'єкт A і успішно завершується оператором COMMIT. Транзакція 1 повторно читає об'єкт A і бачить його змінений стан. Щоб уникнути неповторюваних читань, до завершення транзакції 1 ніяка інша транзакція не повинна змінювати об'єкт A. У більшості систем це є максимальним вимогою до синхронізації транзакцій, хоча, як ми побачимо трохи пізніше, відсутність неповторюваних читань ще не гарантує реальної ізольованості користувачів.
Зауважимо, що існує можливість забезпечення різних рівнів ізольованості для різних транзакцій, що виконуються в одній системі баз даних (зокрема, відповідні оператори передбачені в стандарті SQL 2). Як ми вже відзначали, для підтримки цілісності достатній перший рівень. Існує ряд додатків, для яких першого рівня достатньо (наприклад, прикладні або системні статистичні утиліти, для яких некоректність індивідуальних даних несуттєва). При цьому вдається істотно скоротити накладні витрати СУБД і підвищити загальну ефективність. p> Курсори представляють собою зовсім іншу сутність БД. Однією з найпоширеніших операцій з БД є надання набору інформації за запитом користувача. У реляційній БД це організовується через конструкцію "select ...". Отже, результатом виконання такого запиту буде набір даних, взятий з БД. Однак як отримати доступ до цих даними? Відповідно до нової парадигмою ООП - шаблонами проектування, визначається деякий об'єкт, званий курсором, який виконує функції простого ітератора. Фактично через його інтерфейс користувач в змозі перебирати всі дані, що зберігаються в отриманому наборів довільному порядку.
Такий об'єкт має зазвичай такий інтерфейс:
Init (...); створення ітератора
Bool GetNextInfo (); перейти на наступну порцію даних
GetCurrData (); отримати поточну порцію даних
Ще однією особливістю ітератора є те, що крім перебору даних, він завжди вказує на якусь одну порцію даних.
Природно, поняття курсору тісно пов'язане з механізмом транзакцій.
Дійсно, з моменту виконання запиту з надання курсору клієнту база ні як не блокується і доступна для операцій інших клієнтів. Використання транзакцій дозволило б у випадку конфлікту повернути базу в несуперечливе стан. Тому всі дії з курсором повинні бути обгорнуті в транзакційні дужки.
В
3.Основні відомості з BerkeleyDB
Berkeley DB - В«open sourceВ» бібліотека баз даних, яка забезпечує масштабується, швидкодійне, управління даних, їх захист у додатку. Berkeley DB забезпечує простий функціональний виклик API для доступу до даних і їх управління для безлічі мов програмування, включаючи C, C + +, Java, Perl, Tcl, Pyton, і PHP. Всі операції з базою вчиняються в бібліотеці. Низький рівень операцій включає в себе механізм блокувань, транзакційних блокувань, колективного буферного управління, управління пам'яті і т. п.
За класифікацією BerkeleyDB є навігаційно-мережевий базою з можливістю переміщен...
