Здравствуйте, AndrewVK, Вы писали:

AVK>Извини за философию, но что то меня сегодня на конкретику не тянет . Теперь осталось дождаться ответной философии от IT в защиту стейтлес модели и неделя будет завершена достойно целым философским трактатом

Ok. Но все видели, это не я начал

AVK>Ты можешь и сам прикинуть где такое может быть. Основной недостаток стейтлесс модели — состояние приходится гонять по каналам передачи данных. Если размер такого состояния велик начинаются траблы.

Аргумент отклоняется. Можно подумать, что в стэйтфул ничего гонять не надо. Возьми любой объект, живущий на сервере. Для обращения к его свойствам нужно сделать серверный вызов. Для обращения к одному и тому же свойству два раза, нужно сделать два вызова. Альтернатива — клонирования, но здесь неизбежно упираемся в синхронизацию и версионность.

AVK>Вот например длинные транзакции. Можно конечно долго говорить по поводу того что это зло, но к сожалению очень часто они необходимы именно исходя из бизнес-задачи.

Было бы здорово, если бы ты привёл пример когда без этого не обойтись.

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

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

AVK>Стив Шварц, один из архитекторов СОМ+, а теперь наверное индиги, когда приезжал в Москву сказал примерно следующее:
AVK>никаких стейтлесов не существует в природе. Любой вариант это стейтфул. Вопрос только в одном — в длительности хранения этого самого состояния. Его то по возможности надо минимизировать. То есть в итоге двуполярный "стейтфул/стейтлес" заменяется на градиентное "длительность хранения состояний".

Грамотный мужик. Всё правильно говорит. Вопрос только в том как теперь его мысль интерпретировать.

AVK>А дальше начинается самое интересное. Заученное "стейтлес всегда лучше масштабируется" оказывается не всегда верным! Нет, оно так если все данные под гребенку отнести либо к стейтлес, либо к стейтфул модели. Но мы же договорились что вводим градиентное разделение. А в свете этого мы видим старые и давно известные истины — оказывается данные не однородны. Есть данные меняющиеся крайне редко — например географические справочники. Есть данные средней изменяемости — справочники сотрудников и контрагентов (все это разумеется относительно, для каких то предприятий справочник контрагентов очень чатсо меняется, для каких то наоборот крайне редко, мы берем в среднем по больнице). И, наконец, есть данные, меняющиеся часто — заказы, отгрузки и т.д.

Ok.

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

Ну и что? В стэйтфул вся оптимизация выборки данных работает в холостую и на сложных запросах неизвестно ещё что хуже.

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

Ерунда. Стэйтлес всегда подразумевает, что данные могут быть ещё не подгружены, поэтому при любых намёках на изменения кешированных данных кеш просто элементарно сбрасывается. О блокировках я вообще не понял. В стэйтлес блокировки не нужны.

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

Правильное кеширование в стэйтлес позволяет добиться аналогичных результатов.

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

Ну это так показывает твоя практика. Возьми хотя бы наш сайт, в нём вообще нет долго живущих данных.

AVK>Есть еще одно преимущество стейтфул модели — программирование бизнес-логики в такой модели проще, поскольку не надо все стараться сделать за один чих со стороны клиента, обращение к состоянию не требует потокобезопасности.

Обращение может и не требует, а изменение требует по полной схеме. И об этом нужно помнить всегда, даже когда имплементируешь то же самое обращение. В противовес в стэйтлес о потокоопасности можно практически забыть.

---

На самом деле я вовсе не так против стэйтфул как ты против стэйтлес
Просто при больших нагрузках стэйтфул быстро упирается в ресурсы. То ли в память, то ли в процессор. И не надо говорить что сейчас памяти навалом. Возьмём хотя бы наш сайт, у нас данных в базе на гиг, но если это всё положить в память, в виде найс объектной модели, то сервер сразу ляжет, т.к. под это понадобится в разы больше памяти чем используется БД.

Масштабируемость в стэйтфул — это вообще занятие для мазахистов. Сложность приложения из-за синхронизации увеличивается в разы.

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