"Идеология правильности"

Насколько правилен идеологически такой код (он рабочий):
То есть это Bean имеющий методы, которые используются отдельно. Или правильней завязать это bean к основному JSP через еще какой-нибудь дополнительный класс?

0

В том то и дело что нестатическая. По идее она должна быть одна на все сервлеты.
When the servlet is first created, its init method is invoked, so that
where you put one-time setup code. After this, each user request results
thread that calls the service method of the previously created instance.
Multiple concurrent requests normally result in multiple threads calling service
simultaneously, although your servlet can implement a special interface
that stipulates that only a single thread is permitted to run at any one
The service method then calls doGet, doPost, or another doXxx method,
depending on the type of HTTP request it received. Finally, when the server
decides to unload a servlet, it first calls the servlet’s destroy method.

0

Если переменная не статическая, то она в каждой инстанс сервлета будет своя - это 'медицинский факт'.
И это не противоречит приведенной цитате, где сказано, что ..'although your servlet can implement a special interface that stipulates that only a single thread is permitted to run at any one', т.е. если сервлет защищен интерфейсом, то только одному потоку можно с ним работать. Но контейнер может это реализовать двумя способами, о чем было сказано в спецификации, приведенной v_romanov, а именно:

1. Контейнер создает только одну инстанс сервлета и все запросы обрабатываются поочереди. Это то же самое, если методы сервлета обьявить synchronized (нафиг тогда нужен интерфейс SingleThreadModel?). И это есть однопоточная обработка запросов. Один тяжелый запрос затормозит всю очередь.

2. Контейнер может создавать для каждого запроса свою инстанс сервлета. И это будет многопоточная обработка. Если пришел тяжелый запрос, а следом за ним легкий, то легкий скорее всего раньше обработается.

Я проверял на Томкате это следующим образом. В init() и в destroy()сервлета вставил вывод на печать hashCode() инстанса, чтобы убедиться , что создаются и убиваются разные инстансы сервлета. В метод doGet вставил sleep(10000) перед тем как написать что-то в респонс и выйти из сервлета. Сервлет обьявил как SingleThreadModel.
И открыл подряд несколько окон браузера, который нацелен на этот сервлет. Получил такое же количество сообщений из init. Когда Томкат закрывается, то в консоли появляется несколько сообщений из destroy().

0

Все таки simplepilot правильно, отметил, что в западной литературе,
которую я читал SingleThreadModel трактуется как нежелательная.
И как быть с фразой :
<<<В версии Servlets 2.4 это модель объявлена depricated.>>>
Она соответствует истине ? Если так, то преимущества описанные
господином mselez, (а мы его исследованиям безусловно верим) становятся
спорными. Кроме того потоки закрываются после завершения их работы, а
экземпляры сервлетов, как изволил заметить сам господин mselez,
остаются висеть до завершения работы Tomcat. Кроме того : как долго
порождается новый экземпляр сервлета ? Не сожрет ли это время
преимущества от сокращения ожидания ?
Господа, соблаговолите высказать свое мнение по данному вопросу,
поскольку его важность очевидна и для меня пока неоднозначно его решение.

0

Что ж давайте обсудим

И как быть с фразой :
<<<В версии Servlets 2.4 это модель объявлена depricated.>>>
Она соответствует истине ?

Истине она соответствует , с той лишь оговоркой , что не depricated , а deprecated . А говорится про это вот что

Note that SingleThreadModel does not solve all thread safety issues. For example, session attributes and static variables can still be accessed by multiple requests on multiple threads at the same time, even when SingleThreadModel servlets are used. It is recommended that a developer take other means to resolve those issues instead of implementing this interface, such as avoiding the usage of an instance variable or synchronizing the block of the code accessing those resources. This interface is deprecated in Servlet API version 2.4.

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

Кроме того потоки закрываются после завершения их работы, а
экземпляры сервлетов, как изволил заметить сам господин mselez,
остаются висеть до завершения работы Tomcat.

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

Кроме того : как долго
порождается новый экземпляр сервлета ? Не сожрет ли это время
преимущества от сокращения ожидания ?

Я думаю что все сервлет контейнеры загодя создают инстансы сервлетов и образуют из них пул.

0

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

'Я думаю что все сервлет контейнеры загодя создают инстансы сервлетов и образуют из них пул.'

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

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

Управлять статическими переменными в силу их специфики совсем не страшно, а если страшно - не используйте, так как есть переменные экземпляра. Информация сеанса и ДОЛЖНА быть общей, так как мы не знаем какой экземпляр сервлета будет обслуживать следующий запрос того же пользователя.

'Поэтому Sun предлагает самим решать самими подобные проблемы
ничего не предлагая взамен.'
На основании вышесказанного сомневаюсь, что поэтому. Но представьте себе, что Вы используете в своем приложении SingleThreadModel , а Вам вдруг перекрыли в следующей версии контейнера кислород ?

0

vl romanov дал исчерпывающее разьяснение!

Хотелось бы только добавить несколько слов по поводу deprecated. Получается, что Sun не рекомендует применять многопоточную обработку в сервлетах на том основании, что кто-то неправильно понимает суть статических переменных. Как еще можно заставить контейнер создавать новые инстансы сервлетов, кроме как обьявляя их имплементирующими SingleThreadModel? Действительно, взамен ничего не предлагается. Вернее, то, что предлагается (блоки synchronized внутри сервлета) - это переход к работе с одним инстансом сервлета, т.е. однопоточная обработка.

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

0

2mbasil
На мой взгляд, вопрос в том, будут ли контейнеры сервлетов в будующем позволять использовать для каждого запроса свой инстанс сервлета(с пулом или без пула). Важно , чтобы была возможность указать контейнеру, что мы этого хотим (или не хотим). А уж будет это интерфейс или еще как-то, неважно. Но если такой возможности не будет, значит будем одним сервлетом все обрабатывать или откажемся от сервлетов вообще.

0

В статье 'Servlet 2.4: Что ожидать' ( Джейсон Хантер )
по адресу
http://www.javable.com/javaworld/03_03/01/
я нашел такой текст :
'Только один класс будет переведен в не рекомендованные к использованию в Servlet 2.4,
и этот класс в высшей степени заслуживает этого. SingleThreadModel (STM),
который был плохой идеей с самого начала, в 2.4.объявлен не рекомендованным
к использованию. STM — мертв! Долгие лета многопотоковому программированию!
Хотя STM выглядит хорошо с первого взгляда, метод поочередного вызова,
предлагаемый STM в действительности не дает никаких выгод в плане безопасности
потока, он дает лишь ложное чувство безопасности. Группа экспертов единогласно
решила перевести его в разряд не рекомендуемых к использованию. ...'

0

Начали с запрета поинтеров, теперь и до многопотокового программирования добрались )). Кроме утверждений, что это плохо, конкретно ничего не сказано. Если чего нароете, то пишите, мне тоже это интересно.

0

Прочитал я эту статью (http://www.onjava.com/pub/a/onjava/excerpt/jebp_3/index1.html?page=4).

Вот на мой взгляд, основной аргумент против STM:

'Imagine a servlet needing access to a unique resource, such as a transactional database connection. That servlet needs to synchronize against the resource regardless of the servlet's own thread model. There's no difference if two threads are on the same servlet instance or on different servlet instances; the problem is that two threads are trying to use the connection, and that's solved only with careful synchronization.'
Речь идет о том, что преимуществ от многопотоковой обработки нет, потому что если ресурс, к которому сервлет обращается за данными - уникальный, то лучше иметь один сервлет. А если сервлетов будет много, то доступ к ресурсу опять надо синхронизировать. Все верно и никто не спорит.

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

0

Извините, изложу по этому вопросу свои, тривиальные мысли :
1. Мы вынуждены есть то, что преподносит нам американский дядюшка -
нравится нам это или нет.
2. Желательно приложение исполнять децентрализовано :
все запросы принимает сервлет-контроллер, который принимает запросы,
а затем пассует запросы на обработку другим компонентам.
3. Пулами ресурсов ведают и раздают их, также централизовано, специализированне
Java компоненты (не сервлеты).
4. Там, где на сервлет предполагается 'навал' стараемся использовать
переменные экземпляра в режиме только-на-чтение (или не использовать вовсе).
Фиксируемся на использовании только переменных метода. Это не требует синхронизации.
Нет синхронизации - нет очереди.
Покритикуйте меня !

0

А можно пояснить поподробнее фразу 'Фиксируемся ..'. Тема то интересная. Я то же 'за' работу без синхронизации, но не будет ли сервлет ответы посылать не тому клиенту, который просил, а тому, который пришел следом за ним?

0

Специфика использования одного метода многими потоками подталкивает нас к тому,
чтобы не не использовать ничего стабильного в рамках экземпляра, подчеркиваю -
'В рамках ЭКЗЕМПЛЯРА' (статические объекты, пожалуйста, или для потоков
которым мы отвечаем, только-на-чтение : к экземпляру может обращаться и
один адмиистративный поток, которому мы разрешим изменять содержимое переменной).
Для сохранения информации сеанса есть контекст сеанса. Вот он то стабилен.
Зачастую мы этим механизмом в силу привычки пренебрегаем, а зря.
Можно придумать и другие механизмы такого же толка. Таким образом просто
не следует стремиться сохранять информацию стабильной в рамках экземпляра сервлета.
Например хранимые процедуры в Oracle на языке Java (из-за специфики механизма
их использования) пишутся по таким правилам : в них вообще недопустимо
иметь перемнные экземпляра, а только константы.
Все зто несколько противоречит обычному использованию классов,
но с ситуацией просто надо смириться и подладиться к ней.

0

Что касается вопроса
'но не будет ли сервлет ответы посылать не тому клиенту, который просил,
а тому, который пришел следом за ним ?' ответ ясен - этого принципиально
не может быть потому, что для вызова метода, генерирующего ответ контейнер
в любом случае генерирует связанные с КОНКРЕТНЫМ клиентом объекты запрос/ответ.
Даже если мы сделали редирект запроса другому сервлету, все равно связь
с конкретным запросом конкретного клиента передается новому сервлету и остается
нерушимой. Обсуждаемый вопрос на самом деле касается лишь спосба доступа и
persistent состояния объектов внешних по отношению к методу, обрабатывающему запрос.

0

Отцы, желаю здравствовать! Дайте мне свои две копейки тоже приткнуть )

Как я понял, речь идет сразу о многом. Я хочу немного поговорить об STM. Снова и снова повторяю себе постулат: все должно быть разумно, то есть иметь разумное объяснение, и STM, понятно, не исключение. Я, на самом деле, очень хорошо вижу применение этой модели. В то же самое время, понимаю, почему эксперты его перевели в разряд устаревших (deprecated).

Начну с того, когда бы я ее стал применять. Для этого давайте вспомним, что такое реентерабельные операции. По-англйиски thread-safe. Это значит, что два или более клиентов данного сервера (в данном контексте я под клиентами и серверами понимаю поставщиков и потребителей услуг), вызывая операции, не влияют друг на друга. То есть клиент А, вызвав операцию М, получает после возвращения управления именно то состояние сервера, которое он, А, ожидает. Причем, если в то же самое время клиент В делает то же самое с тем же сервером, он тоже получет ожидаемое состояние сервера. Очевидно, что для этого надо иметь столько объектов, хранящих состояние сервера, сколько потоков к серверу обращается. Как этого можно достичь в объектно-ориентированном языке? Двумя путями:
1) иметь объекты, хранящие состояние, и каким-либо образом ассоциировать их с потоком, выполняющим запрос, или
2) объединить stateless код сервера и его сотояние; в этом случае для каждого вызывающиего потока необходимо создавать по объекту-серверу.

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

Говоря о сервлетах, имеем ту же самую картину: либо объект-сервлет не имеет 'встроенного' состояния (распространенный вариант), либо имеет (нераспространенный). Что предлагает STM -- второй вариант. В этом случае мы можем хранить состояние в объекте-сервлете и контейнер нам гарантирует, что состояние ВСТРОЕННОЕ объекта будет изолировано от других потоков.

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

Нужно всегда помнить, что контейнер гарантирует изолированность той части состояния, которая ВСТРОЕНА в объект-сервер. И ничего не гарантирует относительно той, которая распределена по 'общественным местам'. И достигается это самым тупым и самым простым способом: один поток -- один объект.

Практический вывод. Используя STM, можно не заботиться о той части состояния, что встроена в объект сервлета. О той, что храниться, напрмер, в контексте приложения и даже в контексте сессии (так как пользователь может послать второй запрос, не дождавшись ответа на первый), нужно заботиться самому: самому управлять синхронизацией доступа.

Вот такие помидоры. Прошу прощения, если отнял чье-то время )

0

2mbasil:
'ответ ясен - этого принципиально
не может быть потому, что для вызова метода, генерирующего ответ контейнер
в любом случае генерирует связанные с КОНКРЕТНЫМ клиентом объекты запрос/ответ.'
Вот предположим, что прислал клиент запрос и контейнер вызывает метод doGet сервлета и посылает в метод обьекты request/response , связанные с этим клиентом. Пока метод пишет в response ответ, пришел новый запрос от другого клиента и контейнер опять вызывает тот же метод того же обьекта сервлета, но пихает в него новые обьекты request/response . А в сервлете в это время, например, крутится цикл, в котором он пишет в response предыдущего клиента. Мне вот интересно с этой ситуацией разобраться. Я понимаю, что это к сервлетам отношения не имеет, это азы синхронизации функций .

0

2Danissimo
Насколько я понял, эксперты не рекомендуют применять STM не только потому, что это может ввести в заблуждение индусов , а еще и потому, что это не дает НИКАКИХ преимуществ. Очевидно, предполагается, что есть другие, более правильные решения (с преимуществами). Вот и хотелось бы правильную альтернативу найти.

0

2 mselez:
Можно я отвечу за mbasil'а? ) Все будет нормально, ибо тот же самый метод будет выполняться в другом потоке управления (thread).

А теперь за себя. '[...] не рекомендуют применять STM [...], потому что это не дает НИКАКИХ преимуществ.' Заблуждение. По крайней мере я считаю, что, имея голову на плечах, STM выгодно использовать, когда храниьш состояние в объекте сервлета. Например, можно хранить ожидаемый токен для того, чтобы валидировать корректность переходов по формам. Его можно хранить и в сессии и где угодно еще, но можно и в самом сервлете, если используется можель STM. Последний вариант проще кодируется -- воти преимущество. )

На мой взгляд, причиной отказа от STM послужили именно индусы (фигурально выражаясь ).

0

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

Мне представляется правильной концепция, изложенная mbasil выше. Согласен с Danissimo, что STM имеет право на жизнь (хотя в цитируемой выше статье сказано, что создание STM было ошибочным решением).

Маленький вопрос по поводу последнего высказывания Danissimo.
Если мы применяем STM, то для каждого запроса контейнер выделяет свой обьект сервлета. Если мы хотим хранить промежуточные данные в этом обьекте, то все запросы одного клиента должен обслуживать один и тот же обьект сервлета. Как контейнер это может реализовать? Я знаю, что контейнер различает клиентов, извлекая cookie из запроса, и благодаря этой информации для каждого клиента сохраняется обьект сессии (запретит клиент в браузере поддержку cookie - не будет сессии). А справедливо ли это в отношении обьектов сервлета? Наверное, после того как обьект обслужил клиента, контейнер закинет этот обьект обратно в пул? Следовательно, нельзя в обьекте сервлета хранить данные, а можно только в сессии или еще где-то? И нет этого преимущества!

0

Чесно говоря не было времени проверить факт того что метод инит для сервлета вызывается несколько раз, в зависимости от того какое количество сервлетов должно быть в пуле. Моё представление что сервлет в нормальном состоянии всегда один и лишь много тредов существует для обработки запросов клиента. Это позволяет использовать некоторое количество общих переменных которые по умолчанию не синхронизируются но должны на усмотрение разработчика или как другой вариант просто задекларировать сервлет (через наследование) как не безопасный и ограничить тем самым паралельное использование. Нормальным образом я вижу нелепым использовать общие переменные изза проблем с синхронизацией. Темболее можно использовать ServletContext или Session объект с той же целью. Но когда мы говорим о JSP мы имеем другую логическую модель. В которой общие переменные по тем или иным причинам используются сплош и рядом. Поэтому в этом случае очень часто требуется думать о том
как они используются и в конечном итоге их синхронизировать. Но отдавая должное практическим тестам msaliz я пока от дальнейшей дискуссии воздержусь и продолжу её после того как вернусь из отпуска
и сделаю пару тестов :-)

0