В каком сценарий с сохранением информации лучше, чем не сохраняющий состояние для сети?
"Состояние состязания" существует, когда многопоточный (или в других отношениях параллельный) код, который получил бы доступ к совместно используемому ресурсу, мог сделать так таким способом как для порождения неожиданных результатов.
Берут этот пример:
for ( int i = 0; i < 10000000; i++ )
{
x = x + 1;
}
, Если бы у Вас было 5 потоков, выполняющих этот код сразу, значение x НЕ закончило бы тем, что было 50,000,000. Это на самом деле менялось бы в зависимости от каждого выполнения.
Это вызвано тем, что, для каждого потока для постепенного увеличения значения x они должны сделать следующее: (упрощенный, очевидно)
Retrieve the value of x Add 1 to this value Store this value to x
Любой поток может быть на любом шаге в этом процессе в любое время, и они могут ступить друг на друга, когда совместно используемый ресурс включен. Состояние x может быть изменено другим потоком в течение времени между x, читается и когда это записывается обратно.
Скажем, поток получает значение x, но еще не сохранил его. Другой поток может также получить тот же значение x (потому что никакой поток еще не изменил его), и затем они оба сохранили бы тот же значение (x+1) назад в x!
Пример:
Thread 1: reads x, value is 7 Thread 1: add 1 to x, value is now 8 Thread 2: reads x, value is 7 Thread 1: stores 8 in x Thread 2: adds 1 to x, value is now 8 Thread 2: stores 8 in x
Условий состязания можно избежать путем использования своего рода блокировка механизм перед кодом, который получает доступ к совместно используемому ресурсу:
for ( int i = 0; i < 10000000; i++ )
{
//lock x
x = x + 1;
//unlock x
}
Здесь, ответ выходит как 50 000 000 каждых раз.
Для больше на блокировке, ищите: взаимное исключение, семафор, критический раздел, совместно используемый ресурс.
4 ответа
Using states generally makes the programmer's job easier.
However, states also introduce all sorts of concurrency issues that are simply not present in stateless situations.
This is essentially the debate between functional and imperative programming.
В нашем проекте используется веб-фреймворк Wicket, который обеспечивает взаимодействие с отслеживанием состояния или без него. Страницы с отслеживанием состояния имеют ряд преимуществ:
- Использование страницы с отслеживанием состояния в калитке упрощает выполнение частичных обновлений страницы с использованием инфраструктуры AJAX калитки.
- Сохранение состояния является более «интуитивной» моделью программирования. Например, в классе страницы калитки я могу объявить частное поле члена на стороне сервера, установить его при загрузке страницы и обращаться к нему снова каждый раз, когда запрос AJAX попадает на страницу для выполнения некоторого обновления.
- Wicket предотвращает наиболее распространенные проблемы параллелизма на веб-уровне, синхронизируя объект сеанса пользователя при обработке запроса.
- Сохранение состояния на стороне сервера может иногда повысить производительность; например, объект, который ' создание занимает много времени, но должно быть доступно для страницы, может быть загружено только один раз при первом создании экземпляра страницы.
Все, что возможно в приложении с отслеживанием состояния, также может быть реализовано как без сохранения состояния - вам просто нужно сохранить состояние на клиенте и отправляйте всю соответствующую информацию о состоянии по каждому запросу.
Ссылка на калитку: http://wicket.apache.org/
Такие вещи, как длинные формы (и действительно все, что требует более одного обновления страницы), намного проще с постоянным состоянием, так как вы действительно можете отслеживать, на какой странице / этапе находится пользователь в простой и понятный способ. Однако лично я не думаю, что такое небольшое преимущество того стоит, но оно во многом зависит от рассматриваемого веб-приложения.
Я нахожусь в лагере клиент-сервер без состояния с сохранением состояния из-за масштабируемости, но когда сталкиваюсь с препятствиями, объясняющими, почему то и это стало труднее реализовать с использованием сервера без состояния, вы как бы смирились с В конечном итоге именно здесь сияет сервер с отслеживанием состояния :). Несмотря на то, что я предпочитаю клиент с сохранением состояния, его нелегко эффективно реализовать с помощью asp.net viewstate, и, возможно, именно здесь Web с сохранением состояния становится практичным. Я думаю, что клиент с сохранением состояния, сервер без состояния позволяет вам лучше знать объем данных, которые передаются между шинами и обратно. Это иногда скрывается до возникновения проблем с использованием модели программирования сервера с сохранением состояния. Кроме того, легко перейти от состояния без состояния к состоянию с полным состоянием (просто игнорируйте информацию о состоянии, которую вы предоставляете, поскольку вы ее уже знаете ...). Сделать наоборот практически невозможно / не стоит того. Еще одна вещь, связанная с использованием сервера с сохранением состояния, заключается в том, что очистка состояния / кеша часто является проблемой, когда вы также используете клиент с полным состоянием. Это просто неинтуитивно и сбивает с толку, ну или просто я :)
В любом случае GWT и многие другие современные инструменты (Silverlight общаются с WCF), похоже, предпочитают клиент с отслеживанием состояния, сервер без состояния из-за проблем с масштабируемостью. Возможно, сервер с отслеживанием состояния должен быть исключением из правила без сохранения состояния ... можно выбирать для каждой страницы / окна. http://groups.google.com/group/google-web-toolkit/browse_thread/thread/2871ef5076c1bdb6/43e7a5377047aa44?#43e7a5377047aa44