якщо якийсь ресурс не можна захопити, то необхідно відмовитись від виконання транзакції.
Існує багато альтернатив обробки даних у мережі. Є дві технології, які використовуються при обробці в мережі: клієнт — сервер і файл — сервер. В обох цих технологіях розподілена база даних зберігається на сервері, а з клієнтських машин здійснюють доступ до даних, які зберігаються на сервері.
Проте ці технології мають суттєву відмінність, яка полягає в тому, що у файл-серверній технології на сервері розміщується лише програмне забезпечення, яке підтримує роботу мережі, та файли бази даних, а все прикладне програмне забезпечення знаходиться на комп'ютерах користувачів, тобто на робочих станціях.
Особливості технології клієнт — сервер полягають у тому, що прикладне програмне забезпечення зберігається не лише на робочій станції, певні його компоненти можуть зберігатися на сервері.
Найбільш популярною зараз є архітектура клієнт — сервер, і більшість сучасних розподілених СУБД орієнтовані та цю технологію розподіленої обробки даних.
Розподілені системи, які підтримують архітектуру клієнт — сервер, можна ще визначити як системи типу: багато-клієнтів/одіїн-сервер чи бигато-клієнтів/багато-серверів. У системах першого типу управління базою даних централізоване і виконується досить просто, оскільки вся база зберігається на одному сервері. У таких системах управління доступом до даних клієнтів зводиться до управління процесами блокування та управління буферами клієнтів.
У системах типу багато-клієнтів/багато-серверів база даних може розміщуватися на кількох серверах і для виконання запитів користувачів потрібна взаємодія серверів одного з одним. Кожна клієнтська машина має свій сервер і на нього направляє запити користувача — нібито працює з централізованою базою. Взаємодії серверів при виконанні запиту прозорі для користувача. У більшості існуючих СУБД реалізовано один із двох типів архітектури клієнт—сервер.
Справді, розподілені СУБД не повинні розрізняти клієнтські та серверні машини. В ідеальному варіанті кожний вузол мережі може виступати залежно від ситуації як клієнт чи як сервер. Така архітектура визначається як рівніїй-до-рівного. Але поки що немає СУБД, які б підтримували цю архітектуру, бо досить складно на програмному рівні реалізувати розподіл даних по багатьох вузлах, а це призводить до ускладнення протоколів управління даними.
6.4. УПРАВЛІННЯ ОДНОЧАСНИМ ДОСТУПОМ ДО ДАНИХ
Робота з базою даних у мережі створює проблему, пов'язану з необхідністю простежування за зміною значень атрибутів, яке виконуюється одним користувачем у процесі здійснення ітеративних операцій пошуку та розрахунків іншим користувачем. Якщо виконуються складні запити, пов'язані з пошуком по багатьох файлах бази даних, користувач може почати операції пошуку при одному стані бази даних, а закінчити зовсім при іншому. Це може виникнути в результаті внесення змін у файли бази даних іншими користувачами. Якщо не виконувати певних дій при досить динамічних змінах БД кількома користувачами, то виявиться неможливим формування коректних звітів на такій базі даних через неузгоджений зміст її файлів.
Під час роботи в мережі можуть виникнути проблеми з розподілом доступу до даних кількох користувачів. Наприклад, при паралельному внесенні змін в один і той самий запис один користувач може стерти зміни іншого користувача. Для вирішення колізій такого плану і забезпечення функціонування бази даних у таких випадках використовується блокування чи інакше — накладання замків (захватів). Блокування виконуються за правилами сумісності блокувань, що виключає виникнення конфліктів типу читання — запис, запис — читання чи запис — запис. Існують три методи блокування: гіентра-лізоване блокування, блокування первинної копії і розподілене блокування [16.]. При і/ентралізованому блокуванні для всієї розподіленої бази даних підтримується єдина таблиця блокувань, яка розміщується на одному з вузлів під управлінням єдиного менеджера блокувань. Менеджер блокувань відповідає за встановлення та зняття захватів від імені всіх транзакцій. Оскільки управління блокуванням зосереджено на одному з вузлів, то воно аналогічно централізованому управлінню одночасним доступом до даних. Такий підхід має певні проблеми при його функціонуванні. По-перше, недостатню надійність, яка при відмові чи недоступності центрального вузла блокувань може призвести до виходу з ладу всієї системи. По-друге, центральний вузол може стати вузьким місцем у системі через великі обсяги обробки даних на ньому і через генерованість навколо нього інтенсивного графіка мережі.
Блокування перегінної копії— це управління одночасним доступом, що, використовується для баз даних з реплікаціями, в яких копії одних і тих самих даних можуть зберігатися на багатьох вузлах. Одна з таких копій виділяється як первинна, і для доступу до будь-якого елемента даних необхідно встановити блокування на його первинну копію. Множина первинних копій відома всім вузлам розподіленої системи, і запити на блокування надходять на ті вузли, де зберігаються ці копії. Якщо в розподіленій базі даних не використовуються реплікації, то механізм блокування первинної копії зводиться до розподіленого блокування. Механізм блокування первинної копії запропонований в розподіленій версії СУБД Ingres.
Розподілене (деііенралізоване) блокування пропонує розподілити обов'язки з управління блокуванням між усіма вузлами системи. Під час блокування згідно з цим механізмом необхідна координація взаємодій менеджерів блокувань кількох вузлів. Цей підхід до блокування усуває недоліки централізованого блокування, пов'язані з перевантаженням централізованого вузла, проте він складніший і характеризується більш високими комунікаційними витратами. Цей алгоритм використовується в системах System R і NonStop SQL.
Блокувати можна весь файл, окремий його запис чи групу записів. При блокуванні система повинна інформувати інших користувачів по мережі про те, що в даний момент виконано блокування. Проте