Привет всем.
тут возник вопрос - с сессиями.. проводил небольшой эксперимент - создавал сервлет в котором в методе service создавал сессию:
HttpSession session = request.getSession();

так вот если на стороне клиента отключить поддержку Cookies то при каждом запросе пользователя с данного хоста будет создаваться объект HttpSession - не является ли это потенциальной возможностью перегрузить сервер Resin экземплярами сессий? Ну и что что время сессии можно установить - даже если поставить минимальное значение жизни - 1 минуту - то в течении 1 минуты можно в цикле наплодить столько сессий - что никакой памяти не хватит. Это разумеется лишь предположение - и я, как новичок, буду продолжать исследовать эту область - тем не менее задаю вопрос гуру. 

Сессия создается для каждого нового клиента. Один раз. Если один и тот же клиент опять заходит на сервер, сессия сохраняется, а не создается новая. Сколько клиентов - столько сессии.

Добавлено @ 21:34 

не будет. Создастья только один раз.  

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

Кажется можно указать какой тип сессии создавать: которая исчезает по таймауту, или которая исчезает как только пользователь покинул сайт.  

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

Таймаут ставил у сессии - 1 минуту.. разумеется все новые уничтожались.. только пока я проводил эксперимент - наплодил объектов около сотни.... а если написать цикл запросов к серверу? что будет? 

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

Добавлено @ 22:02 
авообще все эти вопросы возникли совершенно из другой задачи - мне хотелось как то раскопать в библиотеке com.caucho хоть что нить напоминающее менеджер сессий - чтобы из сервлета иметь возможность управлять активными сессиями... уверен что в Резине это есть но это спрятано...

например интересный класс Jmx - до сих пор немогу понять как им нормально пользоваться... 

У любой сессии есть таймаут, но это таймаут её уничтожения, когда юзер сидит и ковыряет в носу, глядя на страничку. А вот в немедленном уничтожении сессии после закрытия браузера я не уверен. Надо будет поэкспериметировать.


А как ты делал эти запросы - перезапуском браузера, или как-то по-другому? 

насколько я понял при экспериментировании (вариьировании параметра session.setMaxInactiveInterval(int time)) - хотя в спецификации указано что передаваемое значение в секундах - на практике оказывалось в минутах - например при указании параметра равным 1 - сессия существовала минуту неактивности. Меньше задать таймаут не получилось.


1) я в браузере отключил поддержку куков
2) из браузера делал GET запрос к сервлету - причем все время делал refresh страницы - запросы шли одни и те же.. и каждое обращение фиксировалось HttpSessionListener'ом - создавался новый объект HttpSession и у него флаг isNew был true.


вообще насколько мне стало ясно когда я пытался разобраться как работает HttpSession - он работает только на основании Cookie - нет куков - сессия создается как будто бы пользователь зашел в первый раз.. есть куки - контейнер сервлетов ищет в своем Map'e сессий уже созданный экземпляр HttpSession по ключу идентификатора сессии...

Как бы я хотел получить доступ к этому гипотетическому Map сессий в Resin (кто бы знал!  ) - это моя давняя мечта... Не хочется делать собственную коллекцию активных сессий - ведь она существует в resin и по моему где то через JNDI ее можно достать.. только как? 

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

сесия связыватеься с браузером: запустите оперу, IE а фаерфокс с одной машина на один и тот же сайт - создаться 3 сесии  

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

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

И все равно у меня чувство, что где-то я об этом читал. Впрочем, возможно вы правы. Разберусь завтра. 


Хм...я всегда думал, что если куки отключены, сессией все таки можно пользоваться. 

То есть сессия может отслеживаться только этими двумя способами (JSESSION либо куки)? 

Нет. Сессия связывается с еёной ID.  т.е. просто с неким номером который с каждым реквестом должен приходить апп-серверу. другое дело что апп сервер пытаеться выдрать номер от куда только можно и  впервую очередь - из Cookies.
Для простоты: каждый раз когда реквест приходит апп-серверу он обязан сообщить в соответсвии с какой сесией он приперся. если он не сообщит - будет создана новая сесия для него.



Нет 
По умолчанию (ну или в соответствии со спецификацией) сессия может отслеживаться только по JSESSIONID. Но если Cookies включены, то JSESSIONID помещаются в Cookies. Но никто не запрещает вам организовать собственный механизм для отслеживания сесий. 

А чтобы JSESSIONID при необходимости добавлялось в линк нужно вызвать метод encodeURL класса HttpServletResponse.

ну т.е. в простейшем случае, в JSP все линки нужно обработать примерно так:


encodeURL сам решит когда нужно параметр в линк пихать а когда нет   

Это сообщение отредактировал(а) ALKS - 8.5.2006, 11:31

Да ну вас право . Ещё раз: чтобы убить сессию по событию закрытия броузера, апп-сервер должен получить соответсвующий реквест. сам по себе Браузер ничего такого не шлет, но этого можно добиться, нарпимер написав плагин для браузера .
Весьма вероятно есть и другие пути (например java-апплет или ActiveX но я не в том ни в другом почти ничего не понимаю, так что не ругайтесь сильно). В любом случае никто в здравом уме таким извратом страдать не будет  

вот спасибо, не знал этого  буду экспериментировать дальше! 

хороший метод! супер! можно дублировать JSESSIONID как в куках, так и в параметрах GET-запроса.. 

cскажите, а получающаяся ссылка в результате вызова метода response.encodeURL содержит добавленную строку jsessionid=xxxxxxxxxxxxxxxx через разделитель ' ; ' - это специфический разделитель, используемый для сервлетов? либо это какой то стандартный разделитель в GET- запросах?

 

Это сообщение отредактировал(а) UnicornMirage - 8.5.2006, 14:36

и всё таки это можно обойти - вначале вопроса я имел ввиду возможность организации DOS атаки.. предположим пользователь намеренно отключит куки - возьмет GET-запрос и исключит из него jsessionid. будет посылать серверу этот запрос в цикле а тот будет создавать все новые и новые HttpSessions.

что нужно сделать в сервлете чтобы не плодить объекты HttpSession?    

Это сообщение отредактировал(а) UnicornMirage - 8.5.2006, 14:50

я поэтому и назвал jsessionid "почти параметром".
такая форма впихивания jsessionid это спецификация J2EE. т.е. да, это особенность спецификации сервлетов к HTTP (и как следствие к GET) отношения не имеющая. почему так а не иначе - тема отдельного не маленького разговора... 


UnicornMirage, телохранители говорят "если дело дошло до стрельбы, то мы уже облажались". перефразируя: если DOS атака прорваласть до апп сервера, что-то делать уже поздно. С DOS атаками борются совершенно специфицескими методами с помощье спецально программного обеспечения и железа, как правило на уровне фаерволов. это не проблемма разработчика вэб приложения. это проблемма сетевых и системных администраторов. спецификация J2EE не предусматривает никаких механизмов борьбы с DOS атаками. и повторяюсь - на этом уровне это делать уже очень поздно!  

Это сообщение отредактировал(а) ALKS - 8.5.2006, 20:20

Так, товарищи!

Прочитал я, что вы тут намолотили, и решил вмешаться. Понимать, как работают сессии, абсолютно необходимо, а иначе потом может быть мучительно больно.

Прежде всего: Servlets API - есть по сути жабный программный интерфейс для работы с HTTP. Вот от этого давайте и плясать.

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

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

- кукисы:

- URL rewriting:

- SSL сессии.

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

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

Теперь очень важный момент: что такое куки и как они работают. Кука - это, грубо говоря, именованная строка текста, которая сассоциирована с адресом URL или его частью. Хотя кукисы не являются частью текущего стандврта HTTP/1.1, они описаны в RFC 2109 (http://www.w3.org/Protocols/rfc2109/rfc2109) от 1997 г. и поддерживаются всеми современными и не очень браузерами.

Так вот, как куки появляются и что с ними происходит дальше. Инициатива по созданию куки принадлежит серверу: когда он возвращает клиенту ответ HTTP (например, содержимое веб-страницы в HTML), он может при этом предварить собственно содержимое одним или несколькими заголовками HTTP. Согласно RFC 2109, одним из таких заголовков может быть Set-Cookie



Согласно все тому же RFC 2109, браузер (если он поддерживает куки и они не выключены юзером) должен в том или ином виде эту принятую куку сохранить. А вот теперь самое интересное. Что происходит, кода юзер тыкает в ссылку? Правильно, браузер отправляет на сервер соответствующим образом оформленный HTTP запрос. Если при этом на URL ресурса распространяется действие ранее сохраненной куки, то браузер автоматически, не дожидаясь особого приглашения, добавляет к запросу заголовок Cookie:



Таким образом, при первом посещении сайта куки на клиенте еще нет - она появится вместе с ответом сервера. Зато при всех последующих посещениях мы уже по содержанию запроса можем узнать, был ли товарищ у нас раньше. Но - внимание! - мы не можем гарантировать, что он точно НЕ БЫЛ. Как мы используем это знание применительно к сессиям? А вот как.

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

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

Хорошо, если юзер человеческий: ну сколько он там сможет натыкать? Десяток-другой бесполезных сессий. А что если пришел поисковый робот? Апорт, например, может запросто за несколько минут сделать сотни заходов. И если хороших, добропорядочных роботов можно определить по содержимому заголовка User-Agent, то бывают ведь и недобропорядочные (собиратели емейлов, например). которым никакой robots.txt не писан и которые любят маскироваться под человеческие браузеры. А еще бывают выкачивалки, которые в мгновение ока могут наплодить такую кучу сессий, что любой сервер загнется.

Напрашивается вопрос: а что же делать? А делать надо вот что: создать прослойку в веб приложении (например, в виде фильтра, хотя и необязательно), которая будет заниматься предварительной обработкой запросов и выявлять клиентов, для которых создавать сессию нежелательно. Логика обработки может включать:

- определение известных поисковиков;

- хранение истории все хапросов за определенный период времени (скажем, 30 минут), и выявление деятелей, которые заходят слишком часто (идентифицировать, например, по совпадению IP и содержимого User-Agent);

- ведение черного списка IP, и запросы с этих адресов слать лесом немедленно и без церемоний.

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

Трудно? Да, трудно. Но никто ведь и не обещал, что будет легко.

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

На этом можно было бы и поставить точку, но у нас остался нерассмотренным еще один механизм отслеживания сессий: URL rewriting. Если говорить совсем коротко, то вот: НИКОГДА, НИКОГДА не используйте этот механизм. Почему - могу объяснить. Но - отдельно, а то и так пост здоровый получился.
 

Здорово!! [+] Однозначно    

Не, ну он еще спрашивает, а?.. 

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

У меня действительно есть очень умная ссылка: я набрел на нее несколько месяцев назад и сохранил на всякий случай линк: http://servlets.com/archive/servlet/ReadMs...me=jsp-interest

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



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

Что я могу сделать - так это прокомментировать аргументы автора, потому что если не представляешь, что такое URL rewriting, то некоторые вещи могут показаться непонятными. Но это завтра. 

Да вроде всё ясно  

текст отличный, спасибо Stampede.

Но. C первыми двумя доводами я не согласен. 

понятно вполне, что имееться под UGLY urls  плохо например то что такие урлы не любят многие поисковые движки ну и еще есть нюансы. но вы можете переписать урл любый образом. как вам нравиться. нарпимер так: www.mysitecom/app/session/30qwihfdlh/go.html и возвращать его в понятное сервлет контейнеру состояния в фильтре до начала работы.

второй пункт... ну мы написали кастом таг который делает внутри url-rewriting и не только на самом деле таг делает очень много полезной работы а его использование не сложнее обычного <A>. так что простите второй довод откровенная ерунда - песьня о тупых ленивых кодерах 

а насчет безопасности. ХЗ. может быть я не эксперт. но вы знаете, если человек не сможет купить плазменный телевизор за $3000 на магазине под нашим движком только из-за того что он параноик и у него отключены куки - нас повесят  
по нашим логам более 5% клиентов приходят без поддрежки куки = минус 5% продаж??? - наc повесят с особой жестокостью.  

И еще. черные списки на уровне App servera? да я не хочу не то чтобы App server пытался бороться с атаками, я не хочу чтобы даже мой HTTP сервер получал подобный реквесты. вся гадость обязана отсекаться еще на уровне IP пакетов до того как я начал тратить ресурсы сервера где запущено мое приложение на анализ подобных реквестов. аппаратный фаервол выдержит нагрузку на 2 порядка больше чем самый оптимальный сервлет контейнер. да и умеею они в вопросах защиты ну очень много (там даже всякий статистический анализ фуззи логика и эвристика). некоторую оптимизацию можно делать (хотя хи хи некоторые краулеры умеют куки и грамотно юзают сессии. очень грамотно.) но только как дополнение к защите более "низкого" уровня. 

Это сообщение отредактировал(а) ALKS - 9.5.2006, 11:11

большое спасибо за информацию  Вы хорошо поняли мои мысли..
такой вопрос - а если делать сессию по IP - можно ли?  

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

Не совсем понятно, что имеется в виду. UnicornMirage ведь говорит о том, чтобы создавать сессию, привязываясь к IP как средству идентификации клиента. Насколько я знаю, в Servlets API такого не предусмотрено, и тому есть веские причины.

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

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

Я. конечно, маленько утрирую: собственно оплата в нормальном магазине должна идти по HTTPS, но ты понял, к чему я клоню: IP как средство идентификации клиента ни в дугу не годится.
 

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



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

Ну а самая ж*па - это если ты такие урлы поисковикам скормишь. Долго будешь потом удивляться, почему к тебе никто попасть не может 

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

Ну или вот ты говоришь фаервол. Его ведь тоже конфигурять нужно, администрить. Но самое главное: он же не может передать инфу в сервлет. А фильтр - может! Сколько чего нароет, столько и напихает в атрибуты запроса.

Так штаа...  

ну это все очевидно  более милиона пользователей аналогового доступа в нет немецкого провайдера AOL ходят с 4х IP-ов  
я не внимательно прочел вопрос. я думал он спрашивает в контексте DOS атак  ну т.е. каким образом НЕ создавать сессию если IP не нравиться.


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

нормальные поисковики кстати умеют куки и все эти линки с сессиями не попадают туда. 

по поводу фильтра смотри. сначала твой HTTP сервер должен получить запрос и перенаправить его твоему сервлет контейнеру. потом сервлет контейнер должен его преврать в объект HttpRequest и передать фильтру. это очень много работы которая отъедает ресурсы твоего вэб сервера. ещё до того как твой фильтр заработал. так что любаай серьезная атака вынесет твой вэб сервер на два порядка быстрее чем фаерфолл который делает фильтрацию на гораздо более низком уровне затрачивая намного меньше аппаратных ресурсов кроме того я хотел бы посмотреть на сервлетный фильт в полной мере реализуюшил логику интелектульного обнаружения распределенных дос атак. это будет фильтр километровой длины и работать будет с сответсвующей скоростью )

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

ну магазин не магазин но за посетителей надо бороться.  в конце концов они - наши деньги. и я не хочу терять поситителей изза такой ерунды как отсутсвие куки 
5% это 10000 EUR продажного оборота в сутки для вэб магазина бытовой электроники средне-мелкого размера... так что думайте сами...
 

Вот я и говорю: разная у нас аксиоматика 

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

 

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

UnicornMirage, в томкате можно реализовать свой SessionManager. 

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

и вообще что значит "контроллировать список созданных HttpSession" чего ты хочеш добиться? 

хочу сделать статистику на сайте для админов - чтобы видеть в виде таблицы список всех сессий и их атрибутов..
ps: я уже сделал ее как говорил выше с помощью HttpSessionListener - но мне показалось что повторно сохранять объекты HttpSessions в своем Map возможно не эффективно т.к. они уже хранятся в сервлет-контейнере.. ведт извлекаются же они по ключу Request.getSession(key) ?  

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

Запросто  Нужно тока чуть-чуть свободного времени и немного денех за написание сервера 

Зависит от числа сессий - если их сотни или даже тысячи - то будет экономия на спичках - ведь повторно сохраняются-то не сами сессии, а ссылки на них. Когда у меня стояла задача показывать список активных сессий, я делал как раз SessionsListener. А SessionManager переписывал просто ради интереса.  

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

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

  

Это сообщение отредактировал(а) UnicornMirage - 14.5.2006, 12:59

UnicornMirage, вот ссылка.
Я писал наследника от StandardManager.
Тебе еще понадобятся исходники томката - чтобы было понятнее, что делается внутри SessionManager. Документация и javadocs по томкату не всегда актуальны.  

pvo, большое спасибо за ссылку!
хотя я использую Resin, наверное в TomCat это реализовано похоже.. хм.. может мне перейти на TomCat? 
 

 ну Тоmcat эталоном никогда не был. и даже скорее наооборот. 
но всё ранво - брать на себя работу Апп cервера  - путь порочный... 

где-то в сети видел сравнения производительности сервлет-контейнеров - участвовали томкат, резин, ЖиРан, Джетти. Версия томката - 5.0.х, остальных - не помню, но очевидно, что не самые древние. Так вот томкат был среди лидеров. И по распространенности он как-то бьет всех остальных. Так что, де факто  он как раз эталон.



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

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

Тшорт, что-то я про Resin то и забыл  сорри 

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

Одно из сравнений tomcat vs resin vs ...