Ответ на комментарии раздела «Следствия модели параллельности»
Мне кажется, что здесь Мариотт предполагает использование замечательной стратегии размещения объектов. Когда автор утверждает, что «Грин забыл упомянуть о том, что тот же самый трешинг может возникнуть на уровне объектов в системах, в которых используются блокировки на уровне объектов», он не является корректным. Я не говорил об этом, поскольку, если бы в объектной архитектуре имелся этот конфликт, он бы разрешался за счет поддержки очереди запросов блокировок, и для этого бы не требовались возвратные вызовы всех клиентов, у которых соответствующий объект находится в кэше, как это требуется в сервере с архитектурой, основанной на страницах. Я снова предлагал практическую рекомендацию, иллюстрирующую важность стратегий размещения в архитектуре, основанной на страницах. Именно поэтому далее я писал: «Приложения, у которых имеются относительно фиксированные модели с редко конфликтующими обновлениями, хорошо сегментирующиеся в независимый кластер, обычно ведут себя наилучшим образом в архитектурах, основанных на контейнерах и страницах.» Но эту фразу Мариотт не процитировал.
Далее Мариотт утверждает, что «здесь Грин не упоминает о том, что в сервер-ориентированных системах, таких как Versant, по мере возрастания числа пользователей могут быстро проявиться проблемы масштабируемости, поскольку большая часть обработки должна производиться на сервере», и это полностью неверно. Так ведут себя реляционные системы, в которых для доступа ко всем данным используются только запросы, и в этом основной смысл использования термина «баланс» в моей исходной статье. Реляционные системы делают все (выполняют запросы) в серверном процессе, а в некоторых объектных архитектурах, таких как ObjectStore, используется противоположный подход, и все делается в клиентском процессе. В ООСУБД Versant и ее архитектуре, основанной на объектах, устанавливается некоторый «баланс», и на стороне сервера выполняются запросы, а на стороне клиента поддерживаются навигация и кэширование.
