Как мы отмечали выше, приложения САПР нуждаются, кроме средств организации сложных объектов, в расширении и пересмотре понятия транзакции. В.Ким с разными соавторами в [63] предлагал ввести целую иерархию понятий транзакций со своими правилами согласованности и протоколами на каждом уровне, а в [67] предлагалась очень общая модель версий объектов в базах данных САПР. Вообще, последние работы этого автора отличаются слишком большим уровнем общности. Все эти работы содержат интересные предложения, но они настолько далеки от реализации (а гипотетическая реализация их настолько сложна), что практически работы становятся неинтересны. Видимо в этом и разошелся В.Ким с разработчиками XSQL, которые, начиная еще с System R, всегда отличались стремлением к простоте.
Для точности отметим, что в [68] В.Ким возвращается к практическим вопросам реализации систем управления базами данных для САПР. В этой статье утверждается, что основным отличием проводимой им (и другими разработчиками MCC) работы от XSQL является то, что разработчики из Сан-Хосе черезчур заботятся о сохранении неизменной подсистемы управления памятью RSS (на наш взгляд это вполне естественно: прежде, чем менять хорошо зарекомендовавший себя продукт, нужно по крайней мере убедиться в том, что его средства недостаточны).
По этому поводу интересно рассмотреть решение проблемы с длинными "инженерными" транзакциями в XSQL [65]. Управление транзакциями основано на одновременой работе с общей базой данных и набором частных баз данных (последние могут, но не обязаны, располагаться на рабочих станциях). Перед доступом к объекту он должен быть явно перемещен в частную базу данных, и об этом производится запись в специальном управляющем отношении, хранящемся в общей базе данных (делается долговременный захват).
Работа с общей базой данных происходит в терминах традиционных "коротких" транзакций, но конец такой транзакции не приводит к автоматическому снятию долговременных захватов, появившихся при работе этой транзакции. Для обновления объекта в общей базе данных требуется наличие соответствующего долговременного захвата (что в общем случае может потребовать переговоров пректировщиков, одновременно работающих с данным объектом). Долговременные захваты снимаются либо по явной команде, либо при сбросе объекта в общую базу данных.
Заметим, что XSQL обеспечивает работу лишь с общей базой данных. Программное обеспечение частных баз данных может быть очень различно (например, тоже с использованием XSQL или на основе прикладных систем). Главное - это соблюдение правил работы с общей базой данных, а это XSQL гарантирует.
Имеется четкое разделение функций между логическим уровнем XSQL и RSS. Как и в System R, обеспечение синхронизации операций параллельно выполняемых коротких транзакций относится к числу функций RSS. Наличие длинных транзакций вообще неизвестно RSS. Управление ими (впрочем, как видно из изложенного выше, очень простое) осуществляется на логическом уровне RSS.
Трудно сказать, является ли достаточным для инженерных разработок механизм управления транзакциями, реализованный в XSQL. Видимо, об этом можно судить только на основе опыта. В доступных публикациях такой анализ пока не проводился. Но по крайней мере одно преимущество реализации механизма длинных транзакций в XSQL очевидно - это простота и ненакладность (о чем, кстати, можно судить, исходя из небольшого объема данного подраздела, в котором содержится вся существенная информация).
Назад | Содержание | Вперед
