значенням поля а > 5, то предикатне захоплення, попереднє реальному виконанню цієї операції, повинне конфліктувати із захопленням першої транзакції і т.д.
Природно, що чим більш точно формулюється предикат, тим більше реальна паралельність виконання транзакцій в системі з предикатними захопленнями. З цієї точки зору найбільшого рівня асинхронності можна було б досягнути, якщо допустити використання як синхронізаційних предикати умов вибірки, видалення або модифікацій мови SQL (або іншої мови запитів високого рівня). Але з іншого боку, чим більш загальний вигляд предикатів допускається, тим складніше стає проблема виявлення сумісності відповідних захоплень. Досить легко реалізовується система предикатних захоплень, в якій предикати являють собою логічні вирази, що складаються з простих предикатів порівняння полів відносин з константними значеннями. Розробники System R не пішли і на таку систему, але деякі ідеї предикатних захоплень використали.
При наявності тільки покортежних захоплень неясним залишається питання синхронізації в RSS покортежних операцій і операцій створення і знищення відносин і індексів, і доповнення полів до існуючого відношення. Незрозуміло, як поєднувати покортежні захоплення з можливість явного захоплення відношення і т.д. Очевидно, що загальна система предикатних захоплень такі проблеми знімає, але як ми вже відмічали, розробники System R не пішли на її реалізацію. Замість цього був розроблений протокол ієрархічних гранульованих захоплень (з деякими елементами предикатних захоплень).
Основна ідея полягає в тому, що є деяка ієрархія пам'яті зберігання кортежів: сегмент-відношення-кортеж. Об'єкти кожного рівня ієрархії можуть бути захоплені. Крім того, можна захоплювати вказаний діапазон значень будь-якого індексу. Набір можливих режимів захоплень розширяється так званими цільовими (intented) захопленнями. Семантично цільове захоплення "складного" об'єкта (сегмента або відношення) означає намір даної транзакції встановлювати цільові або звичайні захоплення на більш низькому рівні ієрархії. Введені наступні типи цільових захоплень: IX (intented to X), IS (intented to S) і SIX (shared, intented to X).
Захоплення об'єкта в режимі IX відповідає наміру транзакції виробляти захоплення об'єктів нижче по ієрархії в режимах IX або X. Захват об'єкта в режимі IS відповідає наміру транзакції виробляти захоплення об'єктів нижче по ієрархії в режимах IS або S. На кінець, захоплення об'єкта в режимі SIX відповідає захопленню об'єкта в режимі S і наміру транзакції захоплювати об'єкти нижче по ієрархії в режимі X. Із цього слідують наступні правила сумісності захоплень різних режимів: |
X | S | IX | IS | SIX
X | ні | ні | ні | ні | ні
S | ні | так | ні | так | ні
IX | ні | ні | так | так | ні
IS | ні | так | так | так | так
SIX | ні | ні | ні | так | ні
Протокол синхронізації з використанням перерахованих режимів захоплень наступний: щоб захопити об'єкт (наприклад, кортеж відношення) в режимі S (X), треба заздалегідь встановити захоплення в режимі IS (IX) відповідних об'єктів вище по ієрархії (у разі захоплення кортежу - сегмента і відношення); при цьому захоплення повинні встановлюватися, починаючи від кореня ієрархії (в нашому випадку - спочатку для сегмента, потім для відношення і тільки потім для кортежу).
Очевидно, що протокол ієрархічних захоплень вирішує проблему сумісності глобальних захоплень складного об'єкта (наприклад, захоплень відношення в режимі S) із захопленнями підоб'єктів цього об'єкта (кортежів). Але також очевидно, що протокол, взагалі кажучи, не вирішує проблему фантом. Якщо відношення сканується без використання індексу, то відсутність фантом можна гарантувати, якщо заздалегідь захопити все відношення в режимі S. Тоді, відповідно до ієрархічного протоколу, ніяка інша транзакція не зможе занести в це відношення новий кортеж, тому що вона буде блокована при спробі захопити відношення в режимі IX (захоплення відношення в режимах S і IX несумісні). Можна, звичайно, захоплювати все відношення і при скануванні з використанням індексу. Таким чином можна вирішити проблему фантом, але це дуже неефективне рішення, тому що воно різко обмежує можливості паралельного виконання транзакцій. Будь-яка тільки читаюча відношення транзакція конфліктує з будь-ким транзакцій, що змінює це відношення. З іншого боку, в RSS при скануванні відношення по індексу є додаткова інформація (діапазон сканування), яка обмежує безліч кортежів, серед яких не повинен виникати фантом.
Виходячи з цих міркувань, було запропоновано ввести в систему синхронізації елементи предикатних захоплень. Помітимо спочатку, що технічно захоплення сегментів, відносин і кортежів трактуються одноманітно, як захоплення tid'ів. При захопленні кортежу насправді захоплюється його tid. При захопленні сегмента або відношення насправді захоплюється tid описувача відповідного об'єкта у внутрішніх відносинах описувачів таких об'єктів (сегментів і відносин). Пропонувалося розширити систему синхронізації, дозволивши застосовувати захоплення до пари ідентифікатор індексу - інтервал значень ключа цього індексу. До такої пари дозволено застосовувати захоплення в будь-кому з допустимих режимів, причому два захоплення сумісні в тому і тільки в тому випадку, якщо вони сумісні відповідно до приведеної вище таблиці, або вказані діапазони значень ключів не перетинаються.
При наявності такої можливості, якщо відкривається сканування відношення по індексу, відношення захоплюється в режимі IS, і в цьому ж режимі захоплюється пара ідентифікатор індексу - діапазон сканування. При занесенні (видаленні) кортежу відношення захоплюється в режимі IX, і в цьому ж режимі для кожного індексу, визначеного на даному відношенні, захоплюється пара ідентифікатор індексу - значення ключа з кортежу, що порушується операцією. Тоді читаючі транзакції реально конфліктують тільки з тими змінюючими транзакціями, які торкаються діапазон сканування. При цьому вирішується проблема