Hello, "Геннадий Васильев"
>
> Гхм. Отвечу по своему... ммм... опыту. Без stateful обойтись можно практически всегда, только цена такого решения — потеря эффективности.

Все зависит от того, как реализации statefull модели. Можно, как говорит AVK, гонять состояние по каналам передачи данных. Это не самый удачный выбор (хотя, если состояние небольшое, то это выход) каналы обычно не резиновые, и в данном случае все возможности масштабирования приложения просто упрутся в толщину канала.

> IT>Что касается хранения состояния в БД, так где же ему ещё храниться как не в БД. Точно так же можно сказать, что делая стэйтфул модель, ты всего лишь изобретаешь ещё один велосипед и создаёшь ту же самую БД, только в памяти и со своим API
>
> В точку. С той лишь разницей, что эта БД — специализированная и потому более эффективно работающая.
>

Глубоко сомневаюсь на счет эффективности. stateless модель будет легко масштабироваться просто добавлением еще одного сервера. Для statefull это окажется достаточно не тривиальной задачей и рано или поздно — приложение упрется в физические возможности конкретной машины. Ну и опять-таки поддержка работы в режиме 24x7 — для stateless это будет достаточно безболезненно, а для statefull придется отключать клиентов и т.п. Хотя, для не критичного приложения уровня подразделения — использование statefull модели — это разумный выбор.

> AVK>>А ведь в чистой стейтлес модели вся логика разруливания между клиентами ложится на sql сервер, который знать не знает и ведать не ведает о предметных свойствах хранимых данных. Вот и получается парадоксальная ситуация — на редко меняемых данных стейтлес модель оказывается хуже масштабируемой из-за неоптимальности и избыточности механики кеширования и блокировок.
>

Для редко меняемых данных — второй SQL сервер и online репликация. Зачем зацикливаться на масштабировании сервиса, в большинстве случаев — многие из этих задач может на себя взять база данных.

> AVK>>В противоположность ей стейтфул модель на таких данных ведет себя хорошо, поскольку гибкое и обладающее большей информацией о предметной области ядро сервера приложений не вносит такого оверхеда. Редко меняющиеся данные спокойно можно постоянно держать в памяти , лишь изредка обращаясь к серверу БД, и не использовать на них практически никаких блокировок поскольку есть определенная гарантия что сильно эти данные не изменяться.

Если использовать этот пример, то можно посмотреть на OODB. Казалось-бы уж кто лучше должен знаеть о том, как устроена объектная модель приложения. Но, где хоть один достойный пример реализации (из тех, что может посоперничать с RDBMS)?

> IT>Правильное кеширование в стэйтлес позволяет добиться аналогичных результатов.
>
> Т.е., по сути — превращение stateless в stateful? Или в терминах Шварца — перемещение в сторону бОльшей длительности хранения промежуточных состояний. Только не забудь о том, что от проблемы синхронзации кэшей в том или ином виде ты не освобождаешься.
>

Наличие кеша — это еще не признак наличия состояния. Преимущество stateless это в аттомарности операций и в том, что никакого промежуточного состояния не сохраняется памяти сервера. т.е. после того, как была выполнена stateless опарация — мы можем забыть о конкретном frontend сервере и следующий запрос может быть с тем-же успехом обслужен любым другим.

> AVK>>Как показывает практика — доля бизнес-сущностей, которые меняются часто невелика, хотя по объему они значительны. Это значит что мы можем написать только небольшую часть бизнес-кода в короткоживущем состоянии.
> IT>Ну это так показывает твоя практика. Возьми хотя бы наш сайт, в нём вообще нет долго живущих данных.
>
> Хотя по сути-то они есть. Те же деревья сообщений и дерево форумов.
>

Все эти деревья никак не относятся к внутреннему состоянию объекта — они хранятся только в БД, а все представления в памяти это просто кеш.

> AVK>>[...] не надо все стараться сделать за один чих со стороны клиента, обращение к состоянию не требует потокобезопасности.
> IT>Обращение может и не требует, а изменение требует по полной схеме. И об этом нужно помнить всегда, даже когда имплементируешь то же самое обращение. В противовес в стэйтлес о потокоопасности можно практически забыть.
>
> Да, как минимум, нужно озаботиться эффективной реализацией Single-Write-Multiple-Read-объектов. Плюс к тому — механизмом синхронизации данных в кластере, буде таковой случится.
>

Single-Write-Multiple-Read — для stateless это задача базы данных. Баз данных у нас опять-таки может быть несколько, и использование репликации снимет проблемы с нагрузкой на конкретный SQL сервер.

Да и кластер — это уже давно пройденный этап. Сейчас в моде grid системы.

> Просто разумный баланс нужен. Никто не мешает, к примеру, кешировать заголовки сообщений, деревья сообщений и деревья форумов. Возможно, так оно и есть на самом деле, я ведь не знаю внутренностей www.rsdn.ru.
>

Кеш и внутреннее состояние — это несколько разные вещи.

> IT>Стэйтфул хорош для приложений с заранее детерминированной нагрузкой. Если можно просчитать, что ресурсов одного компьютера хватит с учётом роста нагрузки и будущих апгрейтов, то вперёд. Но как только одна сущность оказывается одновременно в двух местах, то всё... туши свет, кидай гранату.
>
> Скорее проблема в том, что сейчас практически нет App-серверов, хорошо реализующих stateful-модель.

Причем — все это понимают и именно по этому становится популярной SOA