Соббсно вопрос:
Если я правильно понял....
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 описывается, стоит посмотреть