Архитектура, основанная на контейнерах
Архитектура, «основанная на контейнерах», ориентирована на использование на стороне клиентов. В ней используется стандартная или проприетарная реализация NFS для доставки по сети сегментов диска, называемых контейнерами, клиентам, в которых реализуется большинство функциональных возможностей ООСУБД. Пользовательское приложение компонуется с клиентской библиотекой ООСУБД, которая обеспечивает кэширование контейнеров, обработку запросов, управление транзакциями и жизненным циклом объектов. Каждый объект должен содержаться внутри некоторого контейнера, и любой контейнер может содержать много объектов; может использоваться несколько контейнеров. В этой архитектуре разработчики приложений для обеспечения доступа к объектам базы данных должны основывать модели прикладного уровня на модели контейнеров.
В этой архитектуре параллельный доступ к информации одного контейнера координируется отдельным серверным процессом блокировок. Клиенты взаимодействуют с централизованным процессом блокировок для запросов блокировок контейнеров в каждой базе данных серверной машины до того, как кэшировать контейнер на клиенте путем обращения к серверу страниц NFS. Запрос на обновление ставится в очередь запросов блокировок контейнера, если к этому времени имеются удовлетворенные блокировки контейнера по чтению. Этот запрос либо отвергается по причине превышения максимального интервала времени ожидания, либо удовлетворяется, когда существующие клиенты освобождают свои блокировки. Как правило, блокировки удерживаются в пределах транзакции. После образования очереди по причине поступления запроса блокировки на обновление все последующие запросы блокировок ставятся в очередь вслед за этим запросом. После того, как выполняется обновление, удовлетворяются все стоящие в очереди запросы блокировки на чтение, и, если нет других обновлений, очередь исчезает. Клиенты, кэшировавшие обновленный контейнер, должны при последующем чтении обновить свой кэш. В контейнерах может содержаться много объектов, поэтому возможны ложные ожидания и ложные синхронизационные тупики.
В реализации архитектуры, основанной на контейнерах, используется обработка запросов на стороне клиента. «Клиент» является некоторым процессом, отличным от серверного процесса страниц NFS. Можно сопоставить это с традиционной РСУБД, архитектура которой имеет противоположную природу. В РСУБД все сосредоточено в серверном процессе: обработка запросов, индексация, блокировки и управление страницами, что делает ее реализацию сервер-ориентированной, а не клиент-ориентированной. В реализации архитектуры, основанной на контейнерах, все объекты базы данных, которые затрагиваются запросом, должны идентифицироваться некоторым контейнером базы данных. Этот контейнер содержит все потенциально полезные индексы и загружается в клиентский процесс для выполнения запроса. После загрузки всех потенциально требуемых объектов или индексов и выполнения запроса возвращаемые результаты являются контейнерами, содержащими результирующие объекты, которые удовлетворяют запросу. Тем самым, с точки зрения передачи по сети и блокировки результат может содержать много объектов, которые в действительности не удовлетворяют предикату запроса. Если клиент является удаленным, то результаты попадают в исходные запрашивающий пользовательский процесс через несколько звеньев. Эффективность выполнения запросов может обеспечиваться путем использования общесистемных идентификаторов, многопотоковой, удаленной и распределенной обработки, агрегирования.
Для этой архитектуры единицей пересылки при запросе объекта является контейнер. Все объекты должны располагаться в контейнере, и клиентский запрос объекта разрешается на сервере NFS, посылающем по сети страницы контейнера клиенту, в котором контейнер кэшируются, и обеспечивается последующий доступ к объекту. При пересылке контейнера пересылаются все содержащиеся в нем объекты, независимо от того, требуется ли к ним доступ. Блокировка устанавливается на весь контейнер, независимо от того, к каким объектам требуется доступ запросившей транзакции.