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

А почему же вы сначала пишите что

а теперь что в сессии есть аттрибуты CURRENT_LOGIN и LAST_ACTION_TIME до того, как вы их устанавливаете в с помощью setAttribute()?

Мнэ. Так может поправить логи в ndReportServlet-е, чтобы он писал "ndReportServlet.init:" а не "ndServlet.init:" в логи?

Вы до прошлой пятницы с явой вообще не сталкивались? getClass() это метод Object-а. Просто добавьте скобки.

Давайте так, в начало метода doPost, самыми первыми строчками вы пишите

HttpSession session = request.getSession();
Exception tmp = new Exception();
StringWriter writer = new StringWriter();
tmp.printStackTrace(new PrintWriter(writer));
showInfo("ndServlet@"+hashCode()+".doPost request@"+request.hashCode()+" URL: "+request.getRequestURL()+" Session@"+session.hashCode()+" with ID "+session.getId()+" from cookie? "
+ request.isRequestedSessionIdFromCookie()+" or from URL? "+request.isRequestedSessionIdFromURL()
+ " Stacktrace: "+writer.toString());
Enumeration<?> attributes = session.getAttributeNames();
showInfo("Session Attributes: "+Collections.list(attributes));
while(attributes.hasMoreElements()){
  String name = attributes.nextElement().toString();
  String value = session.getAttribute(name).toString();
  showInfo(name +" = "+value);
}

выдай уже что-нить конструктивное.
-----
Конструктивное тебе УЖЕ дано - ты его просто не воспринимаешь...
Ну попробую так.
Представь себе файл. Ты его один раз прописал и каждый раз читаешь при запуске сервлета... ну скажем в строковую переменную.
Потом ты работаешь с этой строковой переменной - добавил, вырезал, заменил.
Что у тебя будет при следующем запуске сервлета?
Вот это и есть модель работы с сессией - аппсервер как ФСО.
откуда взять getClass для дибага.
-----
Ну Я бы подумал об том откуда в статическом методе возьмется <this>.

Сессия томката не привязана к сервлету. Она привязана к контексту. Несколько сервлетов запущенных в одном контексте могут работать с одной сессией. Даже если сервлет "окончил работу" сессия не исчезает.
Вообще сервлет не должен перезапускаться. Он должен инициализироваться один раз. Но даже если бы он перезапускался он получал бы все ту же сессию.

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

Даже если сервлет "окончил работу" сессия не исчезает.
-----
Исчезает та копия с которой он работал. Остается - та, которая была загружена на аппсервер. В данном случае - ТомКат.
Вообще сервлет не должен перезапускаться. Он должен инициализироваться один раз.
-----
Инстанцируется (или клонируется) при получении запроса. Основание - <HTTP>-протокол есть <state less> протокол
- каждый запрос обрабатывается независимо от предыдущих/других/следующих.
В одиночном томкате сессия простой объект класса HttpSession.
------
Ну начнем с того, что:
- а. у аппсервера не одна <HttpSession>, а набор/коллекция...
- б. коллекция - именно у аппсервера, а не у отдельная сессия у сервлета...
- в. инстансе сервлета работает с копией/клоном сессии хранимой аппсервером.
Просто протестируй - там элементарно все проверяется.
Сохранять сессию имеет смысл только для обмена ею с другими приложениями / вебконтейнерами.
------
Тяжело.
Остается только спросить - что будет при многократных, до окончания выполнения, запросах (и запусках)
сервлета и хранении в сессиях каких-то промежуточных данных? Ну скажем запрет на повторный вход в
контекстно-критическую секцию кода... при условии, что она критична только для данной копии сервлета.
Как будешь разгребать? Ответ - никак - у тебя нет доступа к другому инстансу. Почему этой проблемы нет?
Да потому что копия сессии у каждого своя. А оригинал - у аппсервера.

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

Нет. RTFM. Сервлет - синглтон (если ручками не поломать это поведение). Один и тот же объект используется разными потоками.

Логика! Убил. А может тогда весь сервер перегружать для каждого запроса? Ведь "<HTTP>-протокол есть <state less> протокол".
А зачем вообще придумали сессии не подскажете?

И? А небо голубое, а травка зеленая.

Кто вам такое рассказал? Multiple servlets executing request threads may have active access to a single session object at the same time. The Developer has the responsibility for synchronizing access to session resources as appropriate.
Почитайте http://www.ibm.com/developerworks/library/j-jtp09238/index.html что ли.

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

В нескольких потоках (да-да каждый запрос контейнер обрабатывает в отдельный свободном потоке) будет выполнятся один и тот же код у одного и того же объекта (конечно, внутри потока создается своя "копия" объекта, которая синхронизируется или принудительно, или когда свободное время будет с "оригиналом". Как реализованы потоки на яве вам рассказывать не надо?)
Код сервлета должен быть thread-safe. "Промежуточные данные" следует хранить в сессии не забывая что одноверменно могут работать много потоков. Что опять же в обной и той же сессии происзодит не так часто. При AJAX-овский запросах бывает, да. Или синхронизируем доступ, или привязываем к потоку.

Вы про синхронизацию слышали?

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

ОК, я переставил строчку
showInfo("ndServlet.doPost, Session Attributes: "+java.util.Collections.list(session.getAttributeNames()));
в конец методы. Была моя ошибка, сорри.

Я поправил. Но это была не моя ошибка, оба этих дибаг-аута стояли еще до меня.

Да, ступил Поправил.
P.S. Вместо config.getServletContext().getContextName() написал config.getServletContext().getServerInfo().
У него нет метода getContextName().

Метода init():

-> grep "init() called. Servlet name:" tomcat.log
10.09.2015 15:55:39 I: PP_Servlet (15:55:39):de.novadata.pp.servlet.ndServlet@725887812.init() called. Servlet name: de.novadata.pp.servlet.ndServlet Context Name: Apache Tomcat/5.5.31
10.09.2015 15:56:10 I: PP_Servlet (15:56:10):de.novadata.pp.servlet.ndServlet@1155286236.init() called. Servlet name: de.novadata.pp.servlet.ndServlet Context Name: Apache Tomcat/5.5.31

-> grep "Servlet configuration parameters" tomcat.log
10.09.2015 13:45:54 I: PP_Servlet (13:45:54):Servlet configuration parameters: [HostName, Trace]
10.09.2015 15:55:39 I: PP_Servlet (15:55:39):Servlet configuration parameters: [HostName, Trace]
10.09.2015 15:56:10 I: PP_Servlet (15:56:10):Servlet configuration parameters: [HostName, Trace]
Метода doPost():

10.09.2015 16:07:23 I: PP_Servlet (16:07:23):ndServlet@1155286236.doPost request@850145964 URL: /ICM6/servlet/de.novadata.pp.servlet.ndServlet Session@973355524 with ID 71AFAE004EC7552C250523BCBDD847F8 from cookie? true or from URL? false Stacktrace: java.lang.Exception
10.09.2015 16:07:23 I: PP_Servlet (16:07:23):ndServlet@1155286236.doPost request@850145964 URL: /ICM6/servlet/de.novadata.pp.servlet.ndServlet sessionID from cookie? true or from URL? false Stacktrace:
10.09.2015 16:07:23 I: PP_Servlet (16:07:23):ndServlet@1155286236.doPost request@2042657216 URL: /ICM6/servlet/de.novadata.pp.servlet.ndServlet Session@973355524 with ID 71AFAE004EC7552C250523BCBDD847F8 from cookie? true or from URL? false Stacktrace: java.lang.Exception
10.09.2015 16:07:23 I: PP_Servlet (16:07:23):ndServlet@1155286236.doPost request@2042657216 URL: /ICM6/servlet/de.novadata.pp.servlet.ndServlet sessionID from cookie? true or from URL? false Stacktrace:
10.09.2015 16:07:53 I: PP_Servlet (16:07:53):ndServlet@1155286236.doPost request@126617484 URL: /ICM6/servlet/de.novadata.pp.servlet.ndServlet Session@973355524 with ID 71AFAE004EC7552C250523BCBDD847F8 from cookie? true or from URL? false Stacktrace: java.lang.Exception
10.09.2015 16:07:53 I: PP_Servlet (16:07:53):ndServlet@1155286236.doPost request@126617484 URL: /ICM6/servlet/de.novadata.pp.servlet.ndServlet sessionID from cookie? true or from URL? false Stacktrace:
10.09.2015 16:07:53 I: PP_Servlet (16:07:53):ndServlet@1155286236.doPost request@126486410 URL: /ICM6/servlet/de.novadata.pp.servlet.ndServlet Session@973355524 with ID 71AFAE004EC7552C250523BCBDD847F8 from cookie? true or from URL? false Stacktrace: java.lang.Exception
(есчо много, много раз...)

10.09.2015 16:11:53 I: PP_Servlet (16:11:53):Session Attributes: [bindings.listener, CURRENT_LOGIN, LAST_ACTION_TIME, javax.security.auth.subject]
10.09.2015 16:12:23 I: PP_Servlet (16:12:23):Session Attributes: [bindings.listener, CURRENT_LOGIN, LAST_ACTION_TIME, javax.security.auth.subject]
10.09.2015 16:12:23 I: PP_Servlet (16:12:23):Session Attributes: [bindings.listener, CURRENT_LOGIN, LAST_ACTION_TIME, javax.security.auth.subject]
10.09.2015 16:12:53 I: PP_Servlet (16:12:53):Session Attributes: [bindings.listener, CURRENT_LOGIN, LAST_ACTION_TIME, javax.security.auth.subject]
10.09.2015 16:12:53 I: PP_Servlet (16:12:53):Session Attributes: [bindings.listener, CURRENT_LOGIN, LAST_ACTION_TIME, javax.security.auth.subject]
(есчо много, много раз...)

10.09.2015 13:45:54 I: generated test access key = 0.051317529712655574
10.09.2015 15:55:39 I: generated test access key = 0.9605675906009544
10.09.2015 15:56:10 I: generated test access key = 0.6988406994261954

Чушь.
-----
Тестируй. Я, в свое время, бодался с этой проблемой под ВебСферой.
А лучше - почитай там где более просто описано - например у тех же мелкомягких, в популярном изложении.
Это один и тот же явовский объект.
-----
По поводу одного и того же явовского обьекта - повеселил... т.е. сидит себе персистантный сервлет на аппсервере, ждет когда придет запрос, хранит инстансе своей сессии... и тут приходят ему ДВА запроса... да еще и из РАЗНЫХ мест... Ха-ха-ха...
Если не понял юмора - из разных мест - работать он должен с разными <HttpSession>... и - одновремненно...
Тестируй данный момент. Там не сложно - поместил - прочитал - все есть - второй запрос - пусто, но в первом - все еще есть...
Сервлет - синглтон
-----
Ага... Код этого синглтона приведи, плс... а то как-то закрытого конструктора и статического
инстанса не наблюдается... А вот конструктор, если его написать, дергается регулярно...
Это же не <RMI>, а <HTTP>...
Кто вам такое рассказал?
-----
Практика. Старая добрая практика.
Вы про синхронизацию слышали?
-----
Хи-хи... Что с чем и через что? Только не говори, что код сервлета зависит от того на чем его
запускают - на отдельном сервисе или на ферме...
Потому что у тех, кто умеет программировать многопоточные приложения, этой проблемы просто нет.
-----
У тебя много знакомых пишущих многопоточные приложения и зачем-то еще подрабатывающих веб-разработкой?
Веб, по определению, пишут, в основном, полные дилетанты... А вот проблемы - действительно нет.
Как реализованы потоки на яве вам рассказывать не надо?)
-----
Можно, но бесполезно - у меня к ним интерес оч.маленький - не профилное...

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

Вот в БД еще куда ни шло..
-----
Какая разница куда именно писать?
Читать научись, пИсатель!!!

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

Большая.
-----
Еще раз скажу - Читать все же УЧИСЬ!!!
Описана - модель. Не нравится файл - замени на базу, на <MemoryStream>, на клочек бумаги - носитель не важен.
Основной момент заключается в ответе на поставленный вопрос.

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

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

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

У меня "в свое время" ни под сферой ни под томкатом таких проблем не было. При том что у нас был параллельный доступ в одному сервлету в одной и той же сессии (несколько одновременный AJAXовских запросов).
Что дальше?

А зачем мне читать у мелкомягких? С каких пор они что-то делают для явы, да еще и не соответсвующее сановской (теперь оракловской) спецификации?
Под вебсферой можно, например, включить сериализацию запросов. По дефолту запросы с доступом к сессии обрабатываются параллельно. Читайте, если можете: www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd....

"Дядя Петя, ты дурак?" (с) Сервлет не хранит референс на сессию (если не полный илиот его писал). Объект класса HttpSession управляется контейнером. Что такое "персистантный сервлет" в вашем воспаленном мозгу я не знаю. Но в жизни все происходит так:
1. Запускается контейнер.
2. Все сервлеты, сконфигурированные как "инициализируйся при запуске" инициализируются, т.е. контейнер создает ОДИН объект и вызывает у него init(...)
3. Если сервлет не инициализирован а к нему приходит запрос, то при первом запросе контейнер создает ОДИН объект и вызывает у него init(...)
4. При каждом запросе, который обрабатывается сервлетом в своем "worker" Thread-е контейнер смотрит сконфигурирован ли у него сервлет для URL запроса. Если да, то контейнер находит наш ЕДИНСТВЕННЫЙ объект для нужного контекста и запускает в этом потоке метод service(...) который определяет что за запрос пришел и запускает подходящий doXXX(...) метод.
Фсё. Одновременно в 100 разных потоках может работать код из метода doGet() одного объекта. В 50 потоках с сессией А а в остальных 50 с сессией Б. В чем проблема-то?
Да, зная вас, оговорюсь - это стандартное поведение. Можно и на томкате и на (насколько я помню) вебсфере заставить для каждого запроса создавать новый объект сервлета и убивать его после обработки запроса. Что неплохо так поднимает нагрузку. Делается в основном только на тестовых серверах, чтобы обеспечить возможность быстро и ненапряжно перегрузить сервлет. Контейнер также может и просто так прибить сервлет (чтобы память освободит, например) вызвав destory() и к этому тоже надо быть готовым (но можно и запретить).
Можно заставить контейнер создавать несколько копий сервлета. Но стандартное поведение - ОДНА копия. Специально для вас - из спецификаций сервлета. Английский вы вроде бы понимаете...


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

Уй блин. А если у меня другой класс А хранит в хэшмэпе ссылку на объект класса Б, и доступ к нему только через методы класса А, и он гарантирует что в любой момент у меня только один инстанс класса Б есть, то что, я не могу назвать класс Б (в этом контексте) синглтоном?

Фиговая у вас практика. Ни со спецификацией не соотносится, ни с чужими практиками.

Понял - не слышали. synchronized(...){} никогда не видели?
И код сервера таки зависит от того как его будут запускать. Я могу вам такое написать что при попытке запустить его одновременно без sticky sessions на нескольких хостах за лоадбалансером сервлет будет очень весело работать. Например, можно лезть в контекст. А он, в отличие от сессии между хостами не копируется. Вот же засада, да?

Ога. Потому что веб-разработка это не только странички на cms-ах клепать.

Не профильное это слишком мягко сказано.

Ну, как же нам все-таки быть с атрибутом?
Увидели ли Вы в моих логах что-то интересное?

Угу... угу... угу...
Все замечательно... только не работает... Так что или лыжи не смазаны, или что-то еще...
Последний разок с пропадающем из сессии значением Я таки сталкивался не так давно. Но не с Жабой.
Хотя мог работать и с жабой - методика - та же.

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