Что такое сеанс в Java?

Ответ 1

Некоторые [случайные] исправления:

• Вам не нужны механизмы входа/выхода для сеансов.
• В сервлетах Java HTTP-сеансы отслеживаются с использованием двух механизмов: HTTP-cookie (наиболее часто используемый) или перезаписи URL-адресов (для поддержки браузеров без куки файлов или с отключенными файлами cookie). Использование только файлов cookie просто, вам не нужно ничего особенного делать. Для повторной записи URL вам необходимо изменить все URL-адреса, указывающие на ваши сервлеты/фильтры.
• Каждый раз, когда вы вызываете request.getSession(true), объект HttpRequest будет проверен, чтобы найти идентификатор сеанса, закодированный либо в файле cookie OR/AND в параметре пути URL (что следует за точкой с запятой). Если идентификатор сеанса не найден, новый сеанс будет создан контейнером сервлетов (то есть сервером).
• Идентификатор сеанса добавляется к ответу как файл cookie. Если вы хотите также поддерживать повторную запись URL-адресов, ссылки в ваших HTML-документах должны быть изменены с помощью метода response.encodeURL(). Вызов request.getSession(false) или просто request.getSession() будет возвращать значение null в случае, если идентификатор сеанса не найден или идентификатор сеанса ссылается на недействительный сеанс.
• Существует один сеанс HTTP-сессии, так как куки файлы сеансов Java не хранятся в браузере постоянно. Таким образом, объект сеанса не разделяется между клиентами. У каждого пользователя есть своя приватная сессия.
• Сессии автоматически уничтожаются, если не используются в течение заданного времени. Значение тайм-аута можно настроить в файле web.xml.
• Данный сеанс может быть явно недействителен с использованием метода invalidate().
• Когда люди говорят о JSESSIONID, они ссылаются на стандартное имя HTTP файла cookie, используемого для выполнения отслеживания сеанса в Java.

Ответ 2

Я предлагаю вам прочитать tutorial на сеансах Java. Каждый пользователь получает другой объект HttpSession на основе параметра запроса/ответа JSESSIONID, который веб-сервер Java отправляет в браузер. Таким образом, каждый пользователь может иметь атрибут с тем же именем, а значение, хранящееся для этого атрибута, будет отличаться для всех пользователей.

Кроме того, WebContextFactory и WebContext являются классами DWR, которые предоставляют простой способ получить параметры сервлета.

Ответ 3

Как я понимаю, ваши опасения касаются разделения разных пользователей при хранении вещей в HttpSession.

Контейнер сервлетов (например, Tomcat) заботится об этом, используя свой JSESSIONID.

История выглядит следующим образом:

• Пользователь сначала регистрируется на веб-сайте.
• Контейнер сервлета устанавливает COOKIE на пользовательский браузер, сохраняющий UNIQUE JSessionID.
• Каждый раз, когда пользователь ударяет веб-сайт, cookie JSESSIONID отправлено обратно.
• Контейнер сервлета использует это для следить за тем, кто есть кто.
• Точно так же он отслеживает разделения данных. каждый у пользователя есть своя ведро объекты, однозначно идентифицированные JSESSIONID.

Надеюсь, что (хотя бы частично) ответит на ваш вопрос.

Приветствия

Ответ 4

Ваш основной сервлет будет выглядеть как

public class MyServlet{

public doGet(HttpServletRequest req, HttpServletResponse res){
//Parameter true: 
//    create session if one does not exist. session should never be null 
//Parameter false: 
//    return null if there is no session, used on pages where you want to 
//    force a user to already have a session or be logged in
//only need to use one of the two getSession() options here. 
//Just showing both for this test
HttpSession sess = req.getSession(true);
HttpSession sess2 = req.getSession(false); 

//set an Attribute in the request. This can be used to pass new values
//to a forward or to a JSP
req.setAttribute("myVar", "Hello World");
}

}

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

Когда вы имеете дело с DWR WebContext, он просто делает то же самое, что и выше, как правило, объект Request не передается в этот метод, поэтому вы используете WebContext для получения этого запроса для вас.

public class DWRClass {
 public doSomething(){
WebContext ctx = WebContextFactory.get();
HttpServletRequest req = ctx.getHttpServletRequest();
HttpSession sess = req.getSession(); //no parameter is the same as passing true

//Lets set another attribute for a forward or JSP to use
ArrayList<Boolean> flags = new ArrayList<Boolean>();
req.setAttribute("listOfNames", flags);
}
}