Соббсно вопрос:
Если я правильно понял....
jsp страничка(1.jsp) которая содержит всего лишь

Код

<% out.write("hello");  %>

компилируется в класс сервлета? И два запроса к этой страничке повлекут создание двух экзепляров этого класса?

А если есть ещё и 2.jsp - то для неё будет создан ещё один класс сервлета и при обращении Васи, Пети и Коли к этой страничке будет создано 3 экземпляра этого класса?

Пул объектов есть... но, хочется верить, что зависимость не такая линейная
Экземпляр будет создан для отдельного потока сервера. (их число настраивается)
а так один объект может обработать запрос как от Васи так и от Пети ....
ИМХО 3 экземпляра - в случае одновременного обращения.

То есть для отдельного потока - отдельный объект...
Если Вася, Петя и Коля коннектятся - для них(я так понимаю) создаются три потока...
В каждом из них такой объект?
Или один поток может обрабатывать запросы от всех троих? И когда уничтожится объект(пропадёт ссылка на него)?
Неужели объект будет лежать после обращений Коли и ждать появления какого-нить Васи?

Цитата(KostenkoSergey @ 31.10.2005, 18:19)

Пул объектов есть... но, хочется верить, что зависимость не такая линейная smile Экземпляр будет создан для отдельного потока сервера. (их число настраивается) а так один объект может обработать запрос как от Васи так и от Пети ....

Мдя.... всё-таки один объект может целую ватагу процессов обслуживать....
Посему иногда полезно синхронизировать )))
Не дочитал мануал

про потоки - обработчики читал
про несколько потоков сервера в первый раз слышу
где можно про это почитать и какой сервер имеется в виду?


thnx in advance

Цитата(Souljah @ 2.11.2005, 18:50)

про несколько потоков сервера в первый раз слышу где можно про это почитать и какой сервер имеется в виду?

Про потоки сервера знать нужно обязательно, а не то тебя ждут "ужасные опасности и страшные приключения" (с) Сверчок.

Если коротко, то для каждого входящего запроса создается новый поток (на самом деле может браться готовый из пула). Если три человека обратятся одновременно к одной странице JSP, то каждый стопудово получит по отдельному потоку. А вот экземпляров сервлета, который представляет данную страницу, скорее всего будет только один (зависит от реализации/настроек контейнера).

Поэтому, когда пишешь код сервлета/JSP страницы, нужно четко осознавать, что хранить состояние в экземпляре класса может быть чревато.

В качестве вводной (хотя и очень поверхностной) статьи по данному вопросу могу посоветовать вот это:

Write thread-safe servlets

Успехов!

Цитата(Stampede @ 2.11.2005, 21:46)

Write thread-safe servlets

Отличная статья.

Если я все правильно понял, предлагаютсчя три варианта предотвращения ошибок из-за сервлетной многопоточности:
1. Избегать использования полей в классе сервлета, стараться обходиться локальными переменными, при необходимости - передавать их в виде аргументов;
2. Синхронизировать участки кода
3. Реализовывать интерфейс SingleThreadServlet, при этом контейнер сам позаботится о том, чтобы вызовы этого сервлета обрабатывались исключительно последовательно.

Так?

Lamer George, я не случайно сделал оговорку, что рекомендую статью именно в качестве вводной - только чтобы получить представление о проблематике.

Что касается практических рекомендаций, то тут, боюсь, все обстоит далеко не так просто. В первом приближении, конечно, можно воспользоваться теми предложениями, которые ты суммаризовал (summarized). Или суммировал? Однако, по большому счету, этого отнюдь не достаточно для предотвращения конфликтов. особенно в части доступа к датабазным данным.

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

Если есть желание обсудить/поспорить - буду завсегда рад

Собственно, целью моего summary было именно желание узнать, какие же еще должны/могут использоваться стратегии защиты.

Цитата(Stampede @ 2.11.2005, 23:30)

Вот тут в соседнем треде я предлагаю полностью сериализовать обслуживание всех запросов

В смысле - выстроить их в строгую очередь? Но ведь это будет тот же самый SingleThreadServlet.

Цитата(Stampede @ 2.11.2005, 23:30)

особенно в части доступа к датабазным данным.

Что именно имеется в виду?
В принципе, все конфликты не отловить. Например, у нас - человек заказывает услугу. Если он начнет ее заказывать в 12.00, а подтвердит заказ только в 12.10, то, теоретически, в эти десять минут может вклиниться админ, и удалить этот сервис. Блокировать возможность удаления услуги на эти 10 минут - неразумно. Как быть?..
(ситуация, конечно, редкая. В большинстве случаев операция помещается в одну транзакцию)

Цитата(Lamer @ 2.11.2005, 22:49)

В смысле - выстроить их в строгую очередь? Но ведь это будет тот же самый SingleThreadServlet.

Нет, в общем случае это совершенно разные вещи, по двум причинам:

1. Объявление SingleThreadModel действует только на уровне отдельного класса сервлета. Поэтому к сервлету A будет выстраиваться своя очередь, а к сервлету B - своя. Что есть отнюдь не то же самое, что одна единственная очередь ко всем сервлетам, особенно, повторяю, в ситуации, когда разные сервлеты обращаются к базе данных.

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

Цитата(Lamer @ 2.11.2005, 22:49)

В принципе, все конфликты не отловить. Например, у нас - человек заказывает услугу. Если он начнет ее заказывать в 12.00, а подтвердит заказ только в 12.10, то, теоретически, в эти десять минут может вклиниться админ, и удалить этот сервис.

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

В порядке перенесения обсуждения из другого топика и дальнейшего развития темы:

Цитата(Stampede @ 2.11.2005, 20:09)

Если только не тысяча запросов в секунду, то самая простая стратегия синхронизации, она же самая действенная - это просто тупо сериализовать все входящие запросы.

Цитата(pvo @ 3.11.2005, 00:58)

В целом согласен. Но: 1. Все-таки речь должна идти не о тысячах запрсов в секунду ... Интереса ради попробовал выполнить простой update (изменение одной строки в таблице, кот. имеет 2 индекса и содержит около 50 записей) на локальном Firebird - вместе с коммитом операция заняла от 20ms до 100ms. При работе с удаленной базой время увеличится - будет, скорее всего, от 100ms. ИМХО, тут стоит говорить о максимум 10-20 запросах в секунду. 2. синхронизация методов доступа к базе не спасет, если вдруг захочется запустить приложение в кластере. Или один и тот же код работает в 2 разных веб приложениях.

Очень хорошо, я ждал подобного замечания. И у меня есть наготове ответ.

Значит, предлагаете считать? Давайте. Вот есть такое волшебное число: 86400. Это количество секунд в сутках. От него и будем плясать.

Предположим, у нас достаточно тормозной сервер и неудачно продуманная архитектура приложения, так что на обслуживание запроса уходит в среднем одна секунда (хинт: реально несложно сделать так, что будет работать раз в сто быстрее). Даже в этом случае мы сможем обслужить почти 80000+ запросов в сутки. На самом деле меньше, потому что максимальная пропускная способность будет соответствовать пиковой нагрузке, так что реально мы можем говорить о среднесуточном трафике, примерно вполовину меньшем - то есть 40000 хитов в сутки.

Что такое, товарищи, 40000 хитов? Это очень неслабый трафик. В рунете таким трафиком могут похвастать буквально единицы ресурсов (мы ведь не конкурируем с поисковиками и новостными сайтами). Так вот, даже если мы планируем выйти на уровень, скажем, exler.ru или oper.ru, то мы все еще будем в состоянии справиться со свалившимся нам на голову наплывом посетителей - даже при очень скромных исходных посылках.

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

- отбить трафик в деньги, как минимум достаточные, чтобы оплатить приличный хостинг с хорошим железом;

- сделать редизайн таким образом, чтобы все мослало на порядок быстрее;

- и, таким образом, добиться производительности, позволяющей обслуживать 40000 * 100 = 4 миллиона хитов в сутки в среднем.

А с пропускной способностью в четыре миллиона нам теперь не страшен даже буржуйский интернет.

Вопросы есть? (хинт: должны быть )

Цитата(Stampede @ 2.11.2005, 20:46)

Если коротко, то для каждого входящего запроса создается новый поток (на самом деле может браться готовый из пула).

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

Stampede, предлагаю пока отвлечься от секунд и хитов - я не спорю с тем, что приложение можно оптимизировать таким образом, чтобы при обслуживании каждого запроса оно не гоняло по сети толпу SELECT - ов к базе.

Я зачастую тоже использую описанный метод синхронизации. Он действительно достаточно прост и эффективен, но все сильно зависит от конкретной задачи,на что я и пытался указать.

Например, у нас было несколько заказов, в которых с базой работают ( r/w/d ) 2 и более разных независимых приложений (не только веб приложений). Независимых - написанных разными людьми в разное время на разных языках и с использованием разных идеологий (ситуация не сильно хорошая, но довольно распростаненная у крупных рос. заказчиков). При этом в одной транзакции происходило довольно сложное изменение данных ....
В общем, в такой ситуации синхронизация методов не спасает.

Другой затык может возникнуть при использовании одного кода для доступа к базе в разных приложениях, например при работе приложения в кластере (я имею в виду томкатовский кластер, в котором реплицируются сессии). Хочет, например, заказчик, чтобы была обеспечена отказоустойчивость ...

Цитата(Souljah @ 2.11.2005, 18:50)

про потоки - обработчики читал про несколько потоков сервера в первый раз слышу где можно про это почитать и какой сервер имеется в виду?

Сорри, голова совсем не варила, это я так потоки обозвал сгоряча

Хм... Вообще-то я думал о том же о чём и Souljah размечтался - чтоб всегда "железно" экземпляр сервлета - на один поток.
Честно говоря, jsp/servlets только пару дней назад ковырнул, посему возникло много ламерских вопросов которые стыдно задавать до окончательного прочтения какой-нить из открытых книг.

Нннно...

Один рвётся как крик души: ООП( суть и java тоже ) возлюбил за инкапсуляцию.
За то что, реализовав что-то ты можешь это спрятать и сказать что теперь оно работает так как надо. Представляешь себе объект такой маленькой улиткой у которой всё внутри по сценарию и только рожки реагируют на внешний мир. И ей плевать на то, что там у остальных улиток. И, кажется, лучше java такое никто не поддерживает(хотя я всего не знаю ).
И тут возникает обида на сервлеты:
Какого чёрта объект Петиного потока изменяет с Колиным потоком. Может он там какой-нить "ВИЧ" подхватит, а потом Петиному потоку расхлёбываться.
Или я самой парадигмы не понял, и классы сервлетов - это лишь обёрточка, а вся логика и синхронизация ДОЛЖНЫ быть реализованы в других классах? И какое решение ПРЕДЛАГАЕТСЯ СОЗДАТЕЛЯМИ ТЕХНОЛОГИИ JSP/SERVLETS для этих целей?

P.S. Позволю себе вклиниться в разговор умных людей - глядишь и научат . Моя тема - имею право

Цитата(chief39 @ 3.11.2005, 12:03)

Или я самой парадигмы не понял, и классы сервлетов - это лишь обёрточка, а вся логика и синхронизация ДОЛЖНЫ быть реализованы в других классах? И какое решение ПРЕДЛАГАЕТСЯ СОЗДАТЕЛЯМИ ТЕХНОЛОГИИ JSP/SERVLETS для этих целей?

точно!
сервлеты - это всего лишь точки входа в ваше приложение. т.е. логики в них не должно быть (за исключением формирования объектов для jsp вьюшек)
создатели технологии конкретного решения не предлагают, они просто предоставили вам ферймворк
на эту тему дофига написано было.

недавно читал cookbook из commons-command, там как раз решение для web описывается, стоит посмотреть

Цитата(Souljah @ 3.11.2005, 13:02)

недавно читал cookbook из commons-command, там как раз решение для web описывается, стоит посмотреть

Вас из дас, и где это можно найти в нете? Или только бумажный вариант?

упс, перепутал.

commons-chain конечно

Цитата(Souljah @ 3.11.2005, 11:26)

я думал, имеются в виду еще некие сакральные "серверные потоки" - вроде нескольких экземпляров сервера в контексте одного приложения

Я понимаю. тебя смутила вот эта фраза:

Цитата(KostenkoSergey @ 31.10.2005, 18:19)

Экземпляр будет создан для отдельного потока сервера. (их число настраивается)

Увы, это просто товарищ не совсем удачно выразился. Так что чуда не произошло, никаких сакральных серверных потоков не обнаружилось. И слава богу! Еще всяких сакральных потоков нам только не хватало

Цитата(pvo @ 3.11.2005, 11:33)

Я зачастую тоже использую описанный метод синхронизации. Он действительно достаточно прост и эффективен

Это просто чудо, что ты тоже так думаешь, потому что тотальная сериализация - это такая чудовищная крамола, что никто про это даже и заикаться не смеет.

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

Why shouldn't we make the service() method synchronized?

Цитата

Meanwhile, the first thread finishes executing the service(...) method, so it releases the lock on the servlet instance. One of the other threads--not necessarily the second thread, so we'll say the eighth thread--awakens to find the servlet's lock available, so it requests the lock and starts processing the service(...) method. Meanwhile, the servlet container may be receiving other requests. It's possible that when the eighth thread (which was the second to execute the service(...) method) finishes, the thirty-fifth thread grabs the lock.

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

Потому что если бы ты хоть чуть-чуть умел соображать, то легко прикинул бы хер к носу: хорошо, по какому-то невероятному совпаданию в некий момент к нам вдруг ломанулись в едином порыве 35 юзеров. Ну и фигли? Поставим их в очередь, каждого обслужим за 20 ms, и никто не уйдет обиженным. Самому последнему придется ждать - страшно подумать - целых 0.7 секунды. Тебя бы, дятла, в сибирскую тайгу да на диалап, да дать задание подготовить обзор сайтов на народ.ру

Это про сериализацию. Про доступ из разных приложений цас отдельно напишу.

Это сообщение отредактировал(а) Stampede - 3.11.2005, 23:21

Цитата(pvo @ 3.11.2005, 11:33)

Например, у нас было несколько заказов, в которых с базой работают ( r/w/d ) 2 и более разных независимых приложений (не только веб приложений). Независимых - написанных разными людьми в разное время на разных языках и с использованием разных идеологий (ситуация не сильно хорошая, но довольно распростаненная у крупных рос. заказчиков). При этом в одной транзакции происходило довольно сложное изменение данных .... В общем, в такой ситуации синхронизация методов не спасает.

Да, действительно, тема интранета у нас осталась нераскрытой. От себя добавлю, что это не просто "довольно распространенная у крупных рос. заказчиков", а самая обычная - и в крупных, и в мелких, и в российских, и в нероссийских конторах ситуация.

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

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

В общем, тема тоже интересная

Stampede, у меня вопросина появилась, задал в соседней теме. Если нетрудно, хотел бы выслушать твоё мнение и, желательно, совет.
Особенно если он не будет касаться моей переквалификации )))

Цитата(chief39 @ 4.11.2005, 11:47)

Если нетрудно, хотел бы выслушать твоё мнение и, желательно, совет.

Готово.

Цитата(chief39 @ 4.11.2005, 11:47)

Особенно если он не будет касаться моей переквалификации

Плюс за чувство юмора

chief39, не стыдно не знать чего-то и пытаться искать ответы. Стыдно надувать щеки, корчить из себя эксперта и одарять неразумных перлами мудрости глупости, когда ты элементарно не в ладах со здравым смыслом.

Цитата(Stampede @ 4.11.2005, 13:44)

chief39, не стыдно не знать чего-то и пытаться искать ответы. Стыдно надувать щеки, корчить из себя эксперта и одарять неразумных перлами мудрости глупости, когда ты элементарно не в ладах со здравым смыслом.

Стараюсь...
Стыдно что не дочитал и не углядел.
Скоро ещё вопросов подкину.

Цитата(Stampede @ 3.11.2005, 21:07)

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

Собственно, так и делалось - синхронизация на уровне базы. Конечно, блокировались не целиком таблицы, а строки(мы использовали оракл). А для повышения скорости использовались хранимые процедуры - чтобы не гонять кучу select, update и прочего по сети. В некоторых случаях эти хранимые процедуры уже были, в некоторых приходилось их писать самим.

Цитата(Stampede @ 3.11.2005, 21:07)

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

Один раз делали и кэширование в приложении в такой ситуации - на таблицы невесили триггеры, отправляющие сигналы об изменении данных при завершении транзации - в приложении эти сигналы ловили и обновляли кэш.

Это сообщение отредактировал(а) pvo - 5.11.2005, 12:36

[QUOTE=Stampede,3.11.2005,  20:32]
Про барана вы это метко заметили. Только, извините, на барана вы сам как-то больше похожи.

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

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

В третьих, и в самых важных, тут что-то говорили про крутое оборудование и т.п. А что толку с крутого оборудования, если у вас запросы СЕРИАЛИЗУЮТСЯ? Ну поставь ты хоть 24 процессора, хоть 32 - работать-то будет один. С Сериализацией запросов вы не в состоянии обеспечить загрузку оборудования, это заведомо немасштабируемое решение. 
Настройка приложения - это решение задачи максимальной утилизации имеющихся вычислительных ресурсов, а подход с сериализацией - это декларация своей профнепригодности.

__________________

Автору треда: ну и пусть оно создаёт экземпляры классов на всякий запрос. Храните данные в сессии:

<% 
  javax.servlet.http.HttpSession s = request.getSession();
  Integer i;
  syncronyzed(s){
    i = (Integer)s.getAttribute("i");
    if(i==null) i=0;
    s.setAttribute("i",i+1);
  }

  out.write("hello "+String.valueOf(i++));  
%>

Добавлено @ 03:03 

А почему было не сделать обновление кеша по завершении транзакции?

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

Иначе зачем вам сервер приложений? 

Это сообщение отредактировал(а) 3x3 - 20.9.2006, 03:05

3x3, неплохо, что поднял интересную тему из глубин веков, но вот про барана вспоминать точно не стоило.

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

Между тем я продолжаю утверждать, что в определенных ситуациях полная сериализация таки имеет право на жизнь, а именно - при соблюдении ряда условий, о которых я скажу чуть позже. Что же касается критики, то с грустью приходится констатировать, что гневные нападки догматиков параллелизма лишь подтверждают справедливость ранее высказанного мной наблюдения (позволю себе автоцитату): "большинство типичных аргументов против сериализации - суть бредни записных теоретиков".

Не будем далеко ходить за примерами. Вот что нам сообщают:



Особенно радует вот эта сентенция: "а остальные юзеры и вовсе лапу сосут пока первый высасывает данные". Поясняю для тех, кто "не в теме": как справедливо отметил гневный обличитель, загрузка страницы в общем случае включает в себя несколько циклов запрос-ответ. Сначала загружается собственно текст страницы (как правило, в формате HTML). Затем браузер парсит этот текст и обнаруживает, что страница содержит внешние подгружаемые элементы, такие как файлы стилей, скрипты, картинки и пр. Наконец, для каждого из этих элементов браузер шлет по отдельному GET-запросу.

Как мы видим, товарисч пытается показать, что описанный здесь сценарий представляет собой серьезную угрозу производительности приложения, использующего сериализацию. Спешу вас заранее успокоить: все отнюдь не столь трагично, как нас пугают.

• Прежде всего: подгружаемые элементы - это в подавляющем большинстве случаев статические ресурсы. Чтобы тривиально отдать картинку, нам совершенно нет нужды производить какие-то умопомрачительные вычисления. Как правило, выдачей статического контента занимается отдельный (в большинстве случаев штатный) сервлет, которому совсем не обязательно участвовать в общей сериализации. Более того, если поставить контейнер за Апачем (или другим веб-сервером), то можно сделать так, что запросы на получение статических ресурсов вообще не будут доходить до контейнера.
• Предположим, какая-то часть подгружаемых ресурсов таки действительно генерируется на лету. Например, индивидуализированная "шкурка" (skin) или картинка для CAPTCHA. Поскольку каждый ресурс загружается своим отдельным  GET-запросом, то обслуживание этих запросов на стороне сервера осуществляется в порядке общей очереди. То есть: заявы типа "я от Иван Иваныча" (в смысле, от ранее загруженной страницы), тут не прокатывают. Поэтому страшилка "остальные юзеры и вовсе лапу сосут пока первый высасывает данные" для меня означает одно из двух: либо товарисч не совсем понимает, о чем говорит, либо умышленно искажает факты (любопытно, с какой целью?).
• Ну и до кучи про медленные соединения. "При не очень-то быстрой сети такие задержки добавляют дискомфорт пользователю". При не очень-то быстрой сети дискомфорт определенно наблюдается, но вот какое это отношение имеет к вопросу о сериализации? Прошу обратить внимание, я нигде не говорил, что сериализованная обработка означает долгая обработка. Скорее наоборот, и мы к этому еще вернемся.
  
  К слову, в распоряжении веб-разработчика имеется масса возможностей сделать жизнь пользователя с тонким коннектом по возможности более приятной: компактная верстка, грамотные заголовки кэширования статических ресурсов на стороне клиента, сжатие контента перед отправкой - все это можно и нужно задействовать, но это уже несколько другая тема.

Идем дальше. Что там у нас по списку?



Да похер на самом деле. Все, что нас интересует в этой связи - это величина пиковой нагрузки. То есть количество запросов в единицу времени в период максимального наплыва посетителей. От этой цифры мы и будем плясать при обсуждении условий применимости метода (внимательный читатель, конечно, уже весь извелся от нетерпения, но - всему свое время).

Кстати, в примерах расчетов суточной посещаемости (см. первую страницу топика), над которыми изволит трунить товарисч, я как раз брал пиковую нагрузку как исходный показатель, и уже затем пересчитывал ее в приведенную суточную, каковой цифрой потом и оперировал в дальнейших рассуждениях. Или факт наличия корреляции между пиковой и средней нагрузками вызывает у кого-то сомнение?



Не к чести оппонента, мы опять наблюаем здесь литературный прием под названием подмена понятий. Крутое оборудование - это только лишь много процессоров? А как насчет тактовой частоты, большой памяти, хорошего кэша второго уровня, быстрой дисковой подсистемы, сегментирования базы по множественным дискам? Я уж не говорю о выделении отдельных серверов под СУБД, сервер приложения, веб-сервер и т. д.



Ага, так вот, значит, к чему все это! Значит, когда сервер начнет задыхаться под нагрузкой, мы ему - раз - втыкнем 24 дополнительных процессора, и все опять станет хорошо. Вот ведь как замечательно! А теперь расказываю, как все обстоит на самом деле, ибо это и есть самое интересное.

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

Радости эти примерно такого рода: взаимные блокировки, фантомные чтения, устаревание данных в памяти, и т. д., и т. п. Тут можно попытаться сделать вид, будто база сама разрулит все конфликты (да, в Oracle и Postgres есть очень ловкая штука - многоверсионность по чтению, которая подчас здорово помогает). Ан фигушки. Дело вот в чем.

В любом серьезном приложении в памяти околачивается немалое количество объектов, имеющих датабазное происхождение. То есть: даже если в нем не используется явный программный кэш-менеджер типа Tangosol Coherence, такие объекты - суть программное представление неких датабазных данных. Они могут болтаться в сессиях, в контексте сервлета, в синглтонах - где угодно. При этом их надо каким-то образом держать в согласованном состоянии с подлежащей (underlying) базой: своевременно обновлять, удалять и пр. Это порождает одну маленькую проблему.

Поскольку потоков у нас теоретически больше одного, то методы, изменяющие состояние этих объектов, должны быть в обязательном порядке синхронизированы. Если мы с этой целью тупо объявим их все в виде public synchronized void setParameter(int parameter), то я могу нас сразу поздравить: мы разом получим источник непреходящей острой головной боли на многие годы вперед.

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

Поэтому. Недостаточно просто объявить все методы synchronised. Надо иметь хоть какую-то вменяемую стратегию: что, когда и посредством чего блокировать. Чтобы это стало возможным, необходимо наличие как минимум трех условий:

• программа должна иметь адекватную внутреннюю архитектуру;
• это автоматически подразумевает, что программа должна изначально проектироваться в расчете на высококонкурентный доступ - то есть никакой редизайн/рефакторинг тут не поможет;
• делать это должен человек, который очень хорошо понимает, что такое многопоточное программирование, конкурентное программирование для баз данных, а также как устоена и работает вся система в целом.

Правда жизни, однако, заключается в том, что специалистов, обладающих названными качествами, во всем мире - ну очень немного. Намного меньше, чем проектов, где это требуется. По очень прозаической причине: в силу действия расширенного закона Стёрджена (Sturgeon's Law).

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

Если коротко: полная синхронизация оправдывает себя при выполнении двух условий:

• время отработки запросов находится в пределах одной секунды (в идеале - значительно меньше);
• величина пиковой нагрузки существенно меньше пропускной способности (это не такое уж жесткое условие, если вдуматься).

Обращаю особое внимание на второй пункт, ибо в нем заложен ключ к оценке масштабируемости подхода. Если мы добъемся такой производительности, что запрос будет отрабатывать за, скажем, 50 ms, то будем все еще вполне комфортно чувствовать себя даже на нагрузках порядка 10 обращений в секунду. А это, повторяю, такая нагрузка, которой далеко не каждое приложение может похвастать. Сверх этого порога - это уже совсем другая категория приложений, другие архитектуры и пр. И другая ценовая категория, само собой.

Все, на этом у меня все.

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

Я бы не стал так подробно распинаться, памятуя кое-какие библейские заветы, но тут вот какое дело. Мы с вами находимся на форуме, материалы которого читали, читают и будут читать в веках. У меня здесь есть репутация, которая складывалась не один день и которой я дорожу. И когда приходит какой-то гусь с бугра и сходу делает заявления о моей профнепригодности и позволяет себе хамские, назовем вещи своими именами, реплики в мой адрес, то дать такому гражданину адекватный ответ - это для меня вопрос чести и достоинства.

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

Безо всяких смайлов.

Stampede, 
Я не собираюсь тратить на ваши глупости 6 часов, по этому скажу кратко о том, в чём я с вами согласен, а именно:

• программа должна иметь адекватную внутреннюю архитектуру;
• это автоматически подразумевает, что программа должна изначально проектироваться в расчете на высококонкурентный доступ - то есть никакой редизайн/рефакторинг тут не поможет;
• делать это должен человек, который очень хорошо понимает, что такое многопоточное программирование, конкурентное программирование для баз данных, а также как устоена и работает вся система в целом.

Вот абсолютно с вами в этом согласен по части применения в системах массового обслуживания 


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

PS
Ответными оскорблениями я вас осыпать не стану поскольку у меня нет нужды поддерживать видимость собственной авторитетности ;)

Внимательно перечитал обсуждение. И даже несколько раз. Но вопросы остались...

1) Сериализация запросов и обработка юзверей по очереди. Но разве сериализация - это не способ сохранения объекта в независимом от конкретного приложения состоянии? То есть подход, когда класс имплементит интерфейс java.io.Serializable (или java.io.Externalizable), и может быть сохранён вне программы. Каким образом это связано с входящей очередью пользователей?

2) Как сохранять пользователезависимые значения в JSP/сервлете? Прятать всё в сессию? Писать в кукисы? Каждый раз вызывать

если необходимо сравнить сохранённое значение с константой? Имхо изврат... Есть более человеческие способы работы с уникальными пользователю значениями?

Shaggie

Во-первых, разделение зависит от области актуальности этих данных. Т.е., общие данные, относящиеся к клиент лежат в базе, данные, актуальные для данной сессии - в session, относящиеся к данной машине - в куках, к данному запросу - в локальных переменных, или в request если их надо перебросить в на другую страницу/сервлет в рамках этого запроса.

Плюс, например, если объем данных большой - в сессии/куках их лучше не хранить. В таком случае, их можно сохранить в БД или где-нибудь в собственном хранилище, завязавшись на идентификатор сессии(или, соответственно, идентификатор, записанный в куках). При использовании такого механизма нужно не забывать про очистку этих данных из хранилища после их устаревания.

Shurr, спасибо, общее направление понял, а в частностях как-нибудь сам выход найду.

А про сериализацию кто может помочь прояснить момент?

Да просто термин имеет несколько значений. Такое бывает сплошь и рядом. Сравни, например:

• локализовать программу, и
• локализовать область действия переменной.

Сериализация объектов в некий выходной формат не имеет ничего общего с сериализацией (постановкой в очередь) входящих запросов.

Так что все просто 

 это почему? сессия умирает по таймауту!

Это скорее всего по тому что таймаут бывает разный.
Вообще как я понемаю
когда пользователь закончит работу с приложением ссесия останется открытой до завершения таймаута так зачем это время хранить большые объемы данных?