Здравствуйте, frёёm, Вы писали:
ёё>А чем принципиально будет отличатся stateless по сердствам базы данных от statefull по средствам load balancer'a или иного фасада ?
Load Balancer не сможет расшарить состояние между нодами.
Возвращаясь к примеру с корзиной: Есть два юзера, которые набирают товары в корзину, у одного сессия с одной машиной, у другого с другой.
Состояние корзин в БД не сбрасывается, а торчит в памяти сервера. LB при каждом запросе направляет каждого юзера к своему серверу поддерживая сессию. Теперь появляется администратор, которому надо посмотреть что содержится в корзине у обоих юзеров... Вот этого администратора LB обслужить не сможет, он понятия не имеет, что ему нужны данные с обеих машин, из обоих сессий.
ёё>Мне думается мы говорим об одном и том же ?
Не совсем. LB позволит лишь кешировать запросы конкретного пользователя к своей корзине, но не заменит полноценный statefull сервер.
Здравствуйте, Aikin, Вы писали:
A>Я не понял почему именно оно является определением стэйтфулл/лесс.
Потому что его так определили.
A>Еще раз говорю, в моем понимании стэйтфулл/лесс -- это то что написано у Фаулера, так как я впервые прочитал это у него.
У Фаулера написано совсем не то, что ты понимаешь. Дословно "... не сохраняет данные между циклами обработки отдельных запросов ..." Это ровно то, что утверждаю и я, просто более косноязычно, но Фаулер + переводчик вообще страшная сила.
A>Кроме того я не использовал слова statefull/stateless голословно, я расписал что я имеюю ввиду под ними. После чего достаточно было сказать, что мы просто говорим о разных вещах.
Мы не говорим о разных вещах. Просто ты свое определение придумал, а я говорю об общепринятом.
A>В данном определении слишком тонкая грань между stateless/full.
В природе этой грани вообще нет.
A>Что тут stateless/full сеанс? По Фаулеру можно дать дать одночначный ответ: это statefull сеанс.
По фаулеру это statless приложение. Сессия же, она всегда стейтфул, иначе это не сессия, а просто серия неависимых запросов.
Важные: A>>Фаулер, "Архитектура корпоративных приложений", глава 6 "Сеансы и состояния", цитаты: IB>Я всегда говорил, что неокрепший мозг Фаулер разрывает напрочь.
Да, мозг порван в тряпки. А сейчас я его пытаюсь собрать (с твоей, между прочим, помощью).
A>>Различия между системными и бизнес-транзакциями IB>Отложи пока системные транзакции, бизнес-транзакции и сессии — а то совсем закопаешься.
Эт почему? Сеанс пользователя (от начала наполнения корзины до ее комита) -- это бизнесс транзакция. Очень удобно рассматривать сеанс с этой точке зрения.
Например к атомарности и изоляции транзакции (сеанса) относятся мои слова о том, что данные сеанса не имеют смысла вне самого сеанса.
IB>Они имеют весьма слабое отношение к текущему разговору.
Если текущий разговор о серверах с/без состояния, то я его понимаю (надеюсь на это).
Утрированно: сервер без состояния отвечает на каждый запрос пользователя как на совершенно новый запрос, а сервер с состоянием хранит полную информацию о сеансе пользователя...
$%^, что-то я окончательно запутался
Даже тут ничего сформулировать не могу Что-то мне кажется понятия сервера с/без состояния и сеанса с/без состояния переплетены между собой.
Что-то получается приложение на сервере с состоянием всегда statefull (просто нет вариантов), а на сервере без состояния может быть как stateless (не прикладываем никаких усилий) и statefull (прилагаются усилия, чтобы этот стэйт сохранить/восстановить), похоже на правду?
Прошу помощи:
1) объясните мне разницу в этих понятиях.
2) а надо ли мне понимать эту разницу чтобы писать хорошие приложения?
A>>Теперь вообразите, что ставится задача сбора сведений обо всех кодах ISBN, запрашиваемых клиентом с определенным IP-адресом. Информацию можно располагать в списке, поддерживаемом объектом сервера. В паузах между циклами обработки запросов список должен каким-то образом сохраняться, поэтому речь следует вести об объекте сервера "с состоянием". IB>Опять ты не то выделил. Суть содержится во фразе "Информацию можно располагать в списке, поддерживаемом объектом сервера." Смысл этой фразы в том, что мы добавляем в нашу систему объект "список заказов", и состояние этого объекта не восстанавливается при каждом новом запросе из внешнего хранилища (stateless), а сервер сам держит этот объект в актуальном состоянии между вызовами и помещает в него информацию обо всех новых заказах (statefull). Ровно с тем же успехом я могу при каждом новом запросе восстанавливать этот объект из БД, прошерстив таблицу заказов — и схема волшебным образом становится "stateless".
Нет, я выделил именно то, что хотел выделить, а именно "В паузах между циклами", "каким-то образом сохраняться". Т.е. "каким-то образом", а не обязательно в памяти.
Еще хотел бы выделить слово "может" в твоей цитате. Т.е. это один из вариантов, но отнюдь не единственный. Тем более в этой фразе нет ни слова по внешние хранилища, а дальше (по тексту книги, последняя цитата из книги) говориться что состояние можно хранить как у клиента, так и на сервере (в памяти, в файловой системе, в базе).
A>>Я про standalone приложение (паинт, ворд, фотошоп, ...) в которых данные есть, а stateless понятия нет. IB>Правильно, потому что там нет необходимости восстанавливать состояние при каждом обращении к объекту.
Вот небольшой пример "сеанса без состояния" в нашем общении. Так как эта фраза вырвана их контекста.
Вот контекст: A>>Хотелось бы уточнить что такое state (замечу, что четкой формулировки вчера еще не было, и сформировалось оно в голове у меня только сейчас). A>>State -- это данные имеющие значение только в контексте текущего сианса пользователя (или между запросами пользователя, что еще короче). IB>State — это данные. Все, точка. Это данные, вне зависимости от контекста, не надо придумывать ничего лишнего.
Комментарий> Я ответил, ты зацепился за мое незнание того, что вэб-сервера нужны не только веб-разработчикам, совершенно забыв про начало дискуссии. Я исправился. A>>Не, я не про то говорил. A>>Я про standalone приложение (паинт, ворд, фотошоп, ...) в которых данные есть, а stateless понятия нет. IB>Правильно, потому что там нет необходимости восстанавливать состояние при каждом обращении к объекту.
Ты все еще утверждаешь, что все данные приложения являются "состоянием сеанса"? Или я опять тебя не так понял?
Не важные: A>>только, плиз, аргументированно. IB>Очень знаешь ли сложно говорить аргументировано, в ответ на совершенно неаргументированный поток сознания.
Ну ты же в этом "потоке сознания" разобрался (раз утверждаешь, что там "все не так").
A>> Я здесь для того чтобы учиться. И это самая главная моя цель. IB>У тебя странный способ это делать. Вместо того, чтобы просто спросить, ты придумываешь свою теорию и ждешь, чтобы тебя разубедили.
А чё плохого?
Мне он очень даже нравиться: Я описываю предмет так как его понимаю, после чего достаточно указать в каких местах у меня не так (и главное почему). В самом страшном случае (как по твоим словам этот, нужно сказать что у меня все не так и объяснить как это все на самом деле). Т.е. в этом случае можно воспринимать
A>>Я считаю его необоснованным. IB>Твои проблемы.
На этом можно и закончить дискуссию. Но я еще та достача
A>>Что подразумевается под сервером "без состояния"? Если говорить об объектах, то главное их достоинство состоит в том, что они сочетают в себе состояние (данные) и пове-дение (функции). Объект, лишенный состояния, — это объект без полей данных. Подоб-ные объекты встречаются довольно редко, поскольку считается, что их наличие — при-знак плохого проектирования. IB>Вот это вообще его любимое заблуждение, он немного двинут на своей доменной модели, отсюда и подобные ляпы. Впрочем это так же не имеет отношения к данному разговору.
Это имеет отношения к моему "разорваному мозгу" Я тоже немного двинулся на предметной области. Если я выделю новую тему я могу расчитывать на объяснение почему не всегда домен это хорошо?
IB>А тут еще, похоже, не очень адекватный перевод.
Нуу, а когда нас баловали адекватным переводом?
A>>С другой стороны, однако, это явно не то, что думают многие, когда говорят об "отсутствии состояния" в объектах распределенных корпоративных приложений. Под сервером без состояния понимается объект, который просто не сохраняет данные между циклами обработки отдельных запросов. IB>Вот именно это я и говорил.
Да, но я тоже не утверждал обратного. Кроме того одно из твоих утверждений было про то, что если состояние сохраняется в базе то мы имеем дело с отстутствием состояния.
IB>Обрати внимание так же на то, что это не формальное определение, а то что обычно под этим понимают.
Пнятно, спасибо.
A>> С другой стороны, перечитав первый пост темы, я считаю, что автор имел ввиду именно сеансы с/без состояния. IB>Автор совершенно четко написал, что имел ввиду приложение. IB>А "Сеанс/сессия с состоянием", обычно называется сессия. Просто в EJB под сессией понимается просто единичное обращение к серверу, поэтому там используется термин "сессия с состоянием", чтобы как-то обозначить такого рода сценарии.
В такие тонкости я как-то не хочу (пока) лезть.
A>>И еще: большинство серверов являются серверами без состояния, IB>У тебя есть конкретные цифры?
Проехали, я хотел выкинуть эту фразу, но забыл.
A>> особенно это касается вэб серверов трактующих каждый запрос пользователя как абсолютно новый (именно это я хотел сказать ссылаясь на HTTP). IB>Как я уже неоднократно говорил, совершенно не факт, что ресь идет про веб и http.
Эт я понял, спасибо.
A>>Ключевые фразы в цитатах я выделил. IB>Ты какие-то не те фразы выделил. IB>Мартин, как всегда, в своем репертуаре. Он не привел ни одной четкой формулировки или формального критерия
Да, эт я уже понял (за что тебе большое спасибо).
IB>, но мозг запудрил конкретно, приводя довольно противоречивые примеры и тезисы. Продраться через его весьма многословные описания до сути (хотя иногда оно того стоит) бывает весьма проблематично, так что рекомендую читать его аккуратно и внимательно.
A>>Название темы: "stateless/full web service" IB>Тебя термин web-service смутил? В настоящее время этот термин имеет весьма посредственное отношение к вебу. Например, транспортом может служить MSMQ, tcp/ip, named-pipe, а не только http. Более того, веб-сервисы отлично работают в рамках одной машины для межпроцессного взаимодействия в сугубо десктопных приложениях, какой тут веб?
Понятно.
A>>Не, я не про то говорил. IB>Тебе напомнить что ты говорил? "понятия stateless/full server приминимы только к вэб-разработке" (С) IB>Так вот, этот термин даже появился не в веб-разработке.
Да, эт я погорячился
IB, если я тебя уже в конец достал, можешь не отвечать, я уже итак многое прояснил себе по данному вопросу. Только вот гложат меня сомнения, подогреваемые тобой, что я еще очень далек от понимания.
A>>Я не понял почему именно оно является определением стэйтфулл/лесс. IB>Потому что его так определили.
Да будет так.
Только вот кроме своих слов ты ничем не подкрепил утверждение "что его так определили". Было твое слово против моего (я, как понимаешь, выбрал свое).
A>>Еще раз говорю, в моем понимании стэйтфулл/лесс -- это то что написано у Фаулера, так как я впервые прочитал это у него. IB>У Фаулера написано совсем не то, что ты понимаешь. Дословно "... не сохраняет данные между циклами обработки отдельных запросов ..." Это ровно то, что утверждаю и я, просто более косноязычно, но Фаулер + переводчик вообще страшная сила.
Заметь, ничего не написано про то, что сохранять эти данные в БД нельзя.
В моем понимании, "данные", в этом контексте, это не все данные приложения, а только те, что относятся к сеансу пользователя и только к нему. Т.е. это raw-данные которые не имеют смысла (пока) вне этого сеанса.
Почему я разделяю "данные" на два вида (общие данные приложения и данные конкретного сеанса):
1) если говорить о данных вообще, то никакого понятия (data?) full/less не было бы, потому как все приложения обрабатывают данные;
2) это не просто данные, а данные сеанса (последовательность запросов == транзакция);
3) не надо смешивать (два вида данных) информацию о товаре с тем кто его в конкретный момент положил себе в корзину.
A>>Кроме того я не использовал слова statefull/stateless голословно, я расписал что я имеюю ввиду под ними. После чего достаточно было сказать, что мы просто говорим о разных вещах. IB>Мы не говорим о разных вещах. Просто ты свое определение придумал, а я говорю об общепринятом.
Я его не придумал, а так понял Фаулера.
A>>В данном определении слишком тонкая грань между stateless/full. IB>В природе этой грани вообще нет.
Подробнее, я не понял
A>>Что тут stateless/full сеанс? По Фаулеру можно дать дать одночначный ответ: это statefull сеанс. IB>По фаулеру это statless приложение.
Совсем что-то я запутался. Можешь пояснить?
И почему "приложение"? Каким боком оно тут оказалось? Что означает "statless приложение"?
IB>Сессия же, она всегда стейтфул, иначе это не сессия, а просто серия неависимых запросов.
А никто не говорит, что сессия -- стэйтлесс. Я говорю "неужели если сессия храниться в БД, то это стэйтлесс?"
Здравствуйте, Aikin, Вы писали:
A>Эт почему?
Потому что рано еще. И не имеет никакого отношения к текущему разговору, сначала с серверами разберись.
A>Например к атомарности и изоляции транзакции (сеанса) относятся мои слова о том, что данные сеанса не имеют смысла вне самого сеанса.
Все данные?
A>Даже тут ничего сформулировать не могу Что-то мне кажется понятия сервера с/без состояния и сеанса с/без состояния переплетены между собой.
Вот поэтому я и предлагаю тебе пока забыть про сеансы.
A>Что-то получается приложение на сервере с состоянием всегда statefull (просто нет вариантов), а на сервере без состояния может быть как stateless (не прикладываем никаких усилий) и statefull (прилагаются усилия, чтобы этот стэйт сохранить/восстановить), похоже на правду?
Если у тебя инфораструктура(сервер), поддерживает состояние, то твое приложение, работающее в рамках этого сервера, может быть stateful, без дополнительных усилий. Если же инфраструктура (сервер) не поддерживает stateful, то и твое приложение, все равно будет stateless, до тех пор, пока ты не напишешь свою инфраструктуру умеющую работать с состоянием, поверх имеющейся и скрывающую от твоего приложения stateless природу сервера.
A>1) объясните мне разницу в этих понятиях.
В каких?
A>2) а надо ли мне понимать эту разницу чтобы писать хорошие приложения?
Чтобы писать хорошые приложения, надо понимать что и зачем ты делаешь.
A>Нет, я выделил именно то, что хотел выделить, а именно "В паузах между циклами", "каким-то образом сохраняться". Т.е. "каким-то образом", а не обязательно в памяти.
Каким — действительно не важно, важно что это делаешь не ты, явно, а сервер самостоятельно без твоего участия.
A>Ты все еще утверждаешь, что все данные приложения являются "состоянием сеанса"? Или я опять тебя не так понял?
Я утверждаю, что все данные приложения являются состоянием приложения — забудь про сеансы.
A>Ну ты же в этом "потоке сознания" разобрался (раз утверждаешь, что там "все не так").
Для того, чтобы утверждать, что все не так — разбираться не надо.
A>А чё плохого?
Воинствующий дилетантизм, озлобляет.
A> Я описываю предмет так как его понимаю,
Ты не просто описываешь, ты другим пытаешься ошибочное мнение навязать.
A>Кроме того одно из твоих утверждений было про то, что если состояние сохраняется в базе то мы имеем дело с отстутствием состояния.
Я приводил две позиции — правильную и общепринятую. Правильная заключается в том, что нет никакого stateful/stateless, это лишь вопрос того места где хранится состояние. Общепринятая же утверждает, что statefull — этокогда тебе не надо предпринимать специальных усилий по работе с состоянием объекта при каждом запросе (обращаться к внешнему, по отношению к объекту, хранилищу)
Здравствуйте, Aikin, Вы писали:
A>Только вот кроме своих слов ты ничем не подкрепил утверждение "что его так определили".
Чем ты хотел, чтобы я его подкрепил?
A>Заметь, ничего не написано про то, что сохранять эти данные в БД нельзя.
Именно это я и говорил...
A>В моем понимании, "данные", в этом контексте, это не все данные приложения, а только те, что относятся к сеансу пользователя и только к нему.
Забудь про сеанс, он не имеет никакого отношения к делу.
A>Я его не придумал, а так понял Фаулера.
Окружающие в этом не виноваты.
A>Подробнее, я не понял
Нету stateful и stateless — вопрос лишь в том, где ты хранишь стейт.
A>И почему "приложение"? Каким боком оно тут оказалось? Что означает "statless приложение"?
Что означает "statless приложение" означает, что ты явно следишь за состоянием объекта, доставая его из внешнего хранилища при каждом запросе.
A> Я говорю "неужели если сессия храниться в БД, то это стэйтлесс?"
Забудь про сессии, сначала с приложением вообще разберись.
A>>Например к атомарности и изоляции транзакции (сеанса) относятся мои слова о том, что данные сеанса не имеют смысла вне самого сеанса. IB>Все данные?
Все! Все "данные сеанса". Что это такое я уже говорил.
A>>Что-то получается приложение на сервере с состоянием всегда statefull (просто нет вариантов), а на сервере без состояния может быть как stateless (не прикладываем никаких усилий) и statefull (прилагаются усилия, чтобы этот стэйт сохранить/восстановить), похоже на правду? IB>Если у тебя инфораструктура(сервер), поддерживает состояние, то твое приложение, работающее в рамках этого сервера, может быть stateful, без дополнительных усилий. Если же инфраструктура (сервер) не поддерживает stateful, то и твое приложение, все равно будет stateless, до тех пор, пока ты не напишешь свою инфраструктуру умеющую работать с состоянием, поверх имеющейся и скрывающую от твоего приложения stateless природу сервера.
Наконец пришли к единому мнению.
A>>Нет, я выделил именно то, что хотел выделить, а именно "В паузах между циклами", "каким-то образом сохраняться". Т.е. "каким-то образом", а не обязательно в памяти. IB>Каким — действительно не важно, важно что это делаешь не ты, явно, а сервер самостоятельно без твоего участия.
Тоже согласен
A>>Ты все еще утверждаешь, что все данные приложения являются "состоянием сеанса"? Или я опять тебя не так понял? IB>Я утверждаю, что все данные приложения являются состоянием приложения — забудь про сеансы.
Опять "забудь"
A>>Ну ты же в этом "потоке сознания" разобрался (раз утверждаешь, что там "все не так"). IB>Для того, чтобы утверждать, что все не так — разбираться не надо.
Спорное утверждение.
A>>А чё плохого? IB>Воинствующий дилетантизм, озлобляет.
Профи который ничего не объясняет тоже
A>> Я описываю предмет так как его понимаю, IB>Ты не просто описываешь, ты другим пытаешься ошибочное мнение навязать.
Ткни пальцем где я сказал: "обычно понимают", "заведено", "считают",... вместо обычных для меня: "ИМХО", "я так считаю", ...
A>>Кроме того одно из твоих утверждений было про то, что если состояние сохраняется в базе то мы имеем дело с отстутствием состояния. IB>Я приводил две позиции — правильную и общепринятую. Правильная заключается в том, что нет никакого stateful/stateless, это лишь вопрос того места где хранится состояние. Общепринятая же утверждает, что statefull — этокогда тебе не надо предпринимать специальных усилий по работе с состоянием объекта при каждом запросе (обращаться к внешнему, по отношению к объекту, хранилищу)
Мы тут уже скоро запутаемся, что когда кто сказал (:
A>>Только вот кроме своих слов ты ничем не подкрепил утверждение "что его так определили". IB>Чем ты хотел, чтобы я его подкрепил?
Ссылкой на источник которому можно довериться: MSDN, Вики, статья, блог грамотного специалиста, да мало ли.
A>>Заметь, ничего не написано про то, что сохранять эти данные в БД нельзя. IB>Именно это я и говорил...
Мне самому твои слова процитировать?
A>>В моем понимании, "данные", в этом контексте, это не все данные приложения, а только те, что относятся к сеансу пользователя и только к нему. IB>Забудь про сеанс, он не имеет никакого отношения к делу.
Ок, вернемся позже.
A>>Я его не придумал, а так понял Фаулера. IB>Окружающие в этом не виноваты.
A>>Подробнее, я не понял IB>Нету stateful и stateless — вопрос лишь в том, где ты хранишь стейт.
Могу еще раз спросить "что ты понимаешь под словом стэйт?" Мы так и не пришли к единому мнению.
Я утверждаю, что это "raw-данные" !сеанса!, ты же говоришь, что это вообще все данные.
A>>И почему "приложение"? Каким боком оно тут оказалось? Что означает "statless приложение"? IB>Что означает "statless приложение" означает, что ты явно следишь за состоянием объекта, доставая его из внешнего хранилища при каждом запросе.
Кто, кроме тебя, еще так считает?
A>> Я говорю "неужели если сессия храниться в БД, то это стэйтлесс?" IB>Забудь про сессии, сначала с приложением вообще разберись.
А все же? Типа забегая вперед.
A>>stateless отличается от statefull сервера тем кто хранит это состояние. Сервер с состоянием хранит их у себя, сервер без состояния хранит его не у себя (у пользователя, в скрытом поле, например).
Начнем с того, что тут я действительно ошибался.
A>>stateless отличается от statefull сервера тем кто хранит это состояние. Сервер с состоянием хранит их у себя, сервер без состояния хранит его не у себя (у пользователя, в скрытом поле, например). IB>нет, все не так... IB>Строго говоря, stateless не существует.
Нет, он существует. Но приложение реализованные на нем настолько просты, что никто их уже 100 лет не делал и все о них "забыли".
Типичный пример stateless это www web-server со статическим контентом.
IB>Формально, stateless считается, если состояние объекта приходится явно восстанавливать из какого-нибудь внешнего контейнера при каждом обращении, но это довольно условная граница..
Со словами "явно восстанавливается" я полностью согласен.
А вот используется внешний контейнер или нет, не важно.
Самое главное, ИМХО, прилагаем ли мы, как разработчики, какие либо усилия, чтобы хотя бы понять "был ли этот поьлзователь у нас раньше".
A stateless server is a server that treats each request as an independent transaction that is unrelated to any previous request.
statefull, я так понимаю, это все остальные.
Там же говориться, что даже www сервера не совсем stateless, так как есть куки. Примером statefull server может служить FTP который явно держит сессию с пользователем открытой.
Здравствуйте, Aikin, Вы писали:
A>Все!
Фигню сказал.
A> Все "данные сеанса". Что это такое я уже говорил.
Опять что-то придумал?
A>Спорное утверждение.
Можешь поспорить.
A>Профи который ничего не объясняет тоже
Разжевали уже как для самого маленького, если непонятно — я не виноват.
Здравствуйте, Aikin, Вы писали:
A>Типичный пример stateless это www web-server со статическим контентом.
Контент — это тоже стейт.
A>А вот используется внешний контейнер или нет, не важно.
Без внешнего контейнера явно восстановить не от куда будет.
A>Прав ли я?
нет.
Здравствуйте, Aikin, Вы писали:
A>Ссылкой на источник которому можно довериться: MSDN, Вики, статья, блог грамотного специалиста, да мало ли.
Я — грамотный специалист, мало?
A>Мне самому твои слова процитировать?
Ты их лучше пойми...
A>Могу еще раз спросить "что ты понимаешь под словом стэйт?"
С прошлого ответа ничего не поменялось.
A> Мы так и не пришли к единому мнению.
Это ты не пришел.
A>Я утверждаю, что это "raw-данные" !сеанса!, ты же говоришь, что это вообще все данные.
Задрал ты со своим сеансом. Почему я должен кашу в твоей голове разгребать?
Иди и напиши сто раз — "сеанс не имеет отношения к состоянию сервера"
Пойми ты наконец, понятие statless/stateful сервера формулируется без участия сеансов/сессий, не надо их сюда приплетать.
A>Кто, кроме тебя, еще так считает?
Это общепринятая трактовка.
ОК, не буду ничего додумывать-домысливать. Напишу именно то, что ты пишешь говоря о stateless/full сервере.
Основываться я буду на следующем: IB>По большому счету — все statefull, зависит только от того, насколько далекий путь придется проделать этому самому состоянию, прежде чем добраться до пользователя... IB>Формально, stateless считается, если состояние объекта приходится явно восстанавливать из какого-нибудь внешнего контейнера при каждом обращении, но это довольно условная граница..
A>>Про корзину... IB>Ответ один — это stateless, в общепринятом понимании, но опять-таки повторюсь — граница довольно условна, любому приложению, в конечном итоге, от состояния никуда не деться.
IB>State — это данные. Все, точка. Это данные, вне зависимости от контекста, не надо придумывать ничего лишнего.
IB>Суть я пересказал — стейт никуда не девается, вся разница лишь в том, как далеко он находится от места обработки.
Хоть это и не твои слова, но раз ты ничего не сказал, то будем считать, что LaPerouse все описал верно (тем более это очень похоже на то, что ты говоришь). LP>Мне кажется, ты не понял что имел ввиду ИВ. Когда состояние объекта сохраняется в памяти между сосденими обращениями — это statefull. Когда оно скидывается к примеру в б д и потом восстанавливается при новом обращении — это stateless. При этом ключевым моментом является изменение объекта. В statefull просто меняется объект в памяти, шаренный между обращениями. В stateless состояние меняется локально — мы его меняем только для того, чтобы сохранить в б д измененный объект с целью его восстановления.
IB>Нету stateful и stateless — вопрос лишь в том, где ты хранишь стейт.
Самое полное определение: IB>если состояние после каждого изменения сбрасывается во внешнее хранилище (в частности БД), и при новом обращении достается оттуда, то это stateless.
После сбора информации оказалось, что даже собирать ничего не надо, а можно сразу же тебя процитировать
A stateless server considers each page request independently.
Т.е. стэйтлесс сервер страдает своего рода амнезией и не делает различий между запросом от нового клиента и запросом от клиента, который "секунду назад" тоже что-то спрашивал.
Здравствуйте, Aikin, Вы писали:
A>Теперь скажите как ваше "общепринятное" определение соотноситься со всем следующим:
Что тебя не устраивает в их соотношении?
A>Зато они !все! между собой отлично соотносятся:
A stateless server considers each page request independently.
Если бы сервер сам хранил объект (тебе не пришлось бы его явно сохранять и восстанавливать при каждом запросе), то результат одного запроса (без малейшего усилия с твоей стороны, а исключительно благодаря заботе сервера) влиял бы на другой, и каждый последующий запрос был бы зависим от предыдущего (dependently).
A>Т.е. стэйтлесс сервер страдает своего рода амнезией и не делает различий между запросом от нового клиента и запросом от клиента, который "секунду назад" тоже что-то спрашивал.
Именно. Поэтому в stateless тебе приходится явно сохранять и восстанавливать состояние объекта из какого-нибудь внешнего хранилища при каждом запросе.
Здравствуйте, frёёm, Вы писали:
ёё>Прокоментируйте пажалуйста...
Тут, в общем, есть некоторая сложность.
Грубо говоря, термины stateless и stateful все трактуют несколько по-своему.
С одной стороны, протокол HTTP — stateless. Понять, почему это так, можно путем взгляда в RFC какого-либо stateful протокола, например SMTP.
Типичным элементом такого RFC является диаграмма состояний пользовательской сессии.
В HTTP подразумевается, что вся сессия — атомарный это запрос/ответ, и нет никаких переходов между состояниями.
С другой стороны, даже в базовой спецификации HTTP 1/1 заложены элементы session state. К примеру, клиент может первым действием послать Expect: 100-Continue, после чего получит либо Expectation Failed , либо 100 continue и тогда сделает следуюший ход в рамках той же сессии.
С третьей стороны, у опытных философов сразу возникает вопрос: а как же ухитряются делать stateful сервисы при помощи stateless протокола?
Посмотрим на сервис с несколько большей дистанции. Классическое определение: стейтлесс сервер обрабатывает каждый запрос независимо от предыдущего.
Понятно, что полная независимость достижима только для даосистского сервиса, т.е. такого, для выполнения которого достаточно той информации, которую передает клиент.
К примеру, сервис, который выполняет сложение переданных ему чисел, удовлетворяет требованию statelessness. Совершенно неважно, в каком порядке мы передадим ему запросы (2, 2) и (3, 3) — он всегда вернет 4 и 6 соответственно.
Это может показаться совсем бесполезным — ведь такому сервису всё равно где работать, раз у него нет состояния, то с тем же успехом он может стоять на локальной машине и отвечать на запросы. Однако есть непустой класс сервисов, которые могут быть всё еще полезны — к примеру, если они возвращают что-то более сложное, чем простая арифметика.
Например, сервис, который принимает очень длинное целое и возвращает набор его простых делителей, может оказаться вполне востребован.
Прелесть такого сервиса в том, что его работа не имеет побочных эффектов. Это означает, что результаты всегда можно кэшировать, повышая таким образом масштабируемость нашего раскладывателя на множители.
Однако как правило сервисы создаются в сети как раз для того, чтобы управлять некоторым разделяемым состоянием. К примеру, cервер RSDN имеет в качестве состояния наполнение его форумов и статей, и это состояние является непосредственным результатом действий его клиентов.
Мы можем попробовать применять критерий stateless/stateful не к сервису в целом, а к некоторой его части.
Например, если мы отделим ту часть сервиса, которая отдает HTML странички пользователям, от той, которая хранит собственно данные форумных сообщений, то мы сможем сделать эту первую часть stateless. В целом сервис остался stateful (иначе он был бы бесполезен), но одна из его частей стала stateless.
Это позволяет отдельно масштабировать именно эту stateless часть, хотя очевидно, что ей придется обращаться к stateful, которая рано или поздно станет узким местом.
В примере про веб магазин всё так и происходит — пока корзина между запросами сохраняется в памяти web application, оно остается stateful со всеми трудностями с масштабированием. Как только мы вынесли ее во внешний session storage — оп! приложение стало stateless, хотя с точки зрения пользователя ничего не поменялось.
Это может быть и не преимуществом, а недостатком. Состояние один хрен существует, его необходимо использовать при обработке запросов, но в stateful веб приложении оно лежало "прямо здесь", на расстоянии одного обращения к hash map, а теперь будь любезен сбегать на диск и обратно. Зато, конечно, появляется некоторая надежность: если питание сервера вдруг пропадет, содержимое stateful корзины рассеется словно дым, а stateless корзинка сбегает после включения в СУБД и всё вернет в лучшем виде.
В общем, такая statelessness сама по себе не даст особых преимуществ.
Для того, чтобы понять, как добиться успеха в распределенной среде, нужно отказаться от идеи трактовать сервис как черный ящик.
Поклонники ООП очень любят инкапсуляцию. Вот есть у нас сервис. Это объект, который отвечает на запросы в соответствии со своим состоянием. Остальное типа не ваше, клиентское, дело.
В итоге клиент, который однажды уже получал от сервиса результат 2+2, при повторном вопросе вынужден снова бежать к черному ящику за ответом — ведь состояние сервиса могло измениться после прошлого запроса!
Сервис, который не любит делать лишнюю работу, может приоткрыть завесу тайны над тем, что происходит при обработке запросов.
Запросы к сервису делятся на четыре уровня по отношению к тому, как они взаимодействуют с состоянием сервиса:
1. Запросы, которым для получения ответа состояние вообще не нужно. Вот как с 2+2. Таких, как ни странно, бывает очень много. К примеру, запрос, который формирует PNG картинку с заданным текстом заданным шрифтом заданным цветом.
2. Запросы, которым нужно состояние, но сами по себе они его не меняют (safe requests). Таких еще больше: запрос текущей температуры в Новосибирске, к примеру, на погоду никак не влияет
3. Запросы, которые влияют на состояние, но повторное выполнение имеет тот же эффект, что и однократное (idempotent). К примеру "set a = 5" — это как раз такой запрос. Сколько бы раз мы его не выполняли, наш a будет равен пяти. Их преимущество в том, что если мы не уверены, что запрос дошел, мы можем смело повторять его до тех пор, пока не добъемся однозначного ответа.
4. Все остальные запросы.
Если клиент знает о том, какие запросы как себя ведут, он может построить эффективную стратегию выполнения.
Следующий шаг к успеху — это отказ от "атомарнсти" состояния. Конечно, еще Лейбниц понял, что можно состоянию чего угодно сопоставить одно-единственное число, пусть оно и очень длинное. Вот, допустим, аккаунт пользователя. В нем собрана фотография, имя, фамилия, дата/время последнего входа. Можно сопоставить такому аккаунту число, которое будет изменяться всякий раз, как пользователь входит на сайт.
Но это означает, что все запросы, касающиеся аккаунта, придется повторно выполнять всякий раз.
Если же мы распилим аккаунт на части, то окажется, что некоторые из них изменяются часто, а некоторые — редко.
Это означает, что мы можем придумать эффективную стратегию кэширования состояния, где для обновления копии будет достаточно передавать только относительно небольшую разницу.
Явное описание в протоколе взаимодействия клиент-сервер той части аккаунта, к которой обращен запрос, позволит вообще избежать затрат на синхронизацию состояний в удобных случаях.
Именно на этих идеях построен REST — REpresentational State Transfer. REST — это такое ООП наоборот. В ООП главное — поведение, а состояние вводится только в инкапсулированном виде для того, чтобы обеспечить достаточно сложное поведение.
В REST главное — состояние. Поведение с точки зрения REST классифицируется только с точки зрения того, как оно влияет на это состояние.
Конечно, REST не пытается вообще игнорировать поведение. Даже разбиение состояния системы на составляющие нужно делать с учетом поведения — так, чтобы границы между составляющими максимально соответствовали областям действия нужных нам глаголов.
Например, список статей wikipedia, отсортированный по дате последнего изменения — крайне быстроменяющийся ресурс.
А вот каждая отдельная её статья, как правило, достаточно статична для того, чтобы кэширование стало эффективным.
Другой пример — включать timestamp в тяжеловесную html-страницу. Это примешивает быстроменяющееся состояние к медленно меняющемуся; если уж очень хочется показать часики — вставьте их в iframe; тогда на F5 будет приезжать только минимально необходимая разметка.
Резюме: выбор разработчика вовсе не между stateful и stateless. Выбор — в том, как распределить состояние системы между узлами распределенной гетерогенной сети таким образом, чтобы минимизировать response time и максимизировать throughput.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Мы уже победили, просто это еще не так заметно...
(:
