Работа с сессиями в приложении GWT - PullRequest
5 голосов
/ 09 января 2012

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

Я храню идентификатор сеанса, используя

getThreadLocalRequest().getSession().setAttribute("sid", "randomSIDgoeshere");

Итак,Первый вопрос больше к сервлетам Java, чем к GWT.Гарантирует ли этот код, что в следующий раз я сделаю вызов, подобный этому:

getThreadLocalRequest().getSession().getAttribute("sid");

Это будет либо ноль (в случае, если он вызывается для пользователя, который еще не посетил фрагмент кода, где атрибут SIDустановлено), или это будет точно такой же SID, который я уже сохранил для этого пользователя.Другими словами, являются ли эти 2 фрагмента кода специфичными для пользователя?(под user я имею в виду один браузер на одном компьютере)

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

public class MyGwtServiceImpl extends RemoteServiceServlet implements MyGwtService {
  // SID to User ID mappings
  private final Map<String, String> sessions = 
    new HashMap<String, String>();
  ...
}

Гарантируется ли, что sessions всегда является одним и тем же объектом для всех запросов, и его данные останутся «живыми», если не завершится все приложение?(Tomcat, например, остановлен) Это нормальный подход, или я должен сохранить все эти сопоставления в моей БД?

1 Ответ

7 голосов
/ 09 января 2012

Первый:

Да, это гарантирует. При следующем вызове getThreadLocalRequest().getSession().getAttribute("sid"); при следующем запросе атрибут sid останется там. Но помните, что это локальная область запросов, поэтому только запросы от одного и того же пользователя (browser + ip) должны делиться информацией. Это значит:

Факт:

  • Пользователь A соединяется с Firefox
  • Вы храните случайное значение X с идентификатором Y

Дело 1

  • Пользователь A соединяется с Firefox
  • Вы можете получить X

Дело 2

  • Пользователь A подключается к Google Chrome
  • Вы не можете получить значение X

Дело 3

  • Пользователь B подключается к Firefox
  • Вы не можете получить значение X

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

Второе:

Нет, это не гарантируется. Хотя в большинстве случаев будет вызываться один и тот же номер сервлета, не гарантируется, что он будет существовать всегда. Если вы хотите сохранить атрибуты в вашем сервлете, вы должны объявить эти атрибуты как статические, поэтому статический атрибут THAT не будет зависеть от пользователя. Или вы можете хранить в ServeletContext

Я говорю это потому, что различные реализации (например, Glassfish) могут завершать экземпляры, если сервлет не требуется в течение длительного периода времени (насколько я помню, я не уверен в этом (Glassfish завершает работу экземпляра) ). Но нет документации о том, что она гарантирует, что это будет один и тот же экземпляр, поэтому вы не можете объявлять нестатические атрибуты и делиться между разными экземплярами.

...