2014-12-28 3 views
-1

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

Hashtable<string,MySession> sessions; //sessionid and MySession instance 

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

Вопрос,

  • является threadsafed моя текущая структура? Я имею в виду этот единственный экземпляр сервлета, где я храню всех пользователей в hastable? У меня есть методы хеш-таблицы, такие как addNewSession и clearSession. (Я использую идентификатор сеанса браузера в качестве ключа). Я не делал это методы синхронизированы, так как этот подход не рекомендуется (один экземпляр сервлета)

  • что произойдет, если я объявляю hastable статический, так что я могу добраться до него из обоих новых отделенных сервлетов (логин и операции)

  • Что делать, если я храню этот hastable в родительском сервлете и расширяю логин и операцию от этого сервлета, чтобы оба могли достичь своего родительского сервлета, защищенного экземпляра хэш-таблицы?

  • Использование методов сервлета contenxt, где я получаю другой сервлет из контекста или непосредственно хранят хеш-таблицу в контексте? Будет ли он решать проблемы безопасности потоков? Или я думаю, что должен обеспечить синхронизацию для объекта ServletContext, возвращаемого getServletContext(), потому что он распределяется между сервлетами в myapplication?

Текущая структура:

public SingleServlet extends HttpServlet { 
    Hashtable<string,MySession> sessions = new Hashtable(); 

    public void doGet(HttpRequest request, HttpResponsr response) { 
     String sessionId = request.getSessionId(); 

     if (sessions.get(sessionId) == null) { 
      // Create a new session and store 
      // Do login operations 
      MySession iNewSession = new MySession(..); 

      // Thread safety?? 
      sessions.put(sessionId, iNewSession); 
     } else { 
      // Already existing session, operate on that 
      MySession iExistingSession = sessions.get(sessionId); 

      // Check if operation is logout 
      if (isLogout(request)) { 
       iExistingSession.performLogout(); 

       // Thread safety?? 
       sessions.remove(sessionId); 
      } else 
      iExistingSession.continueOperation(request, response); 
     } 
+3

Почему вы заново изобретаете, что уже делают родные сеансы? –

+0

ты имеешь в виду апач сиро? – benchpresser

+0

Нет, я имею в виду HttpSession. Это именно то, что есть: хеш-таблица для каждого идентификатора сеанса, где вы можете сохранить любой атрибут, который вы хотите. –

ответ

0

Ваш код не является потокобезопасным. Хотя отдельные операции (например, put, get и remove) являются атомными и потокобезопасными, последовательность операций (например, get, за которой следует put) не является потокобезопасной.

+0

Я считаю, что ConcurrentHashMap под java.util.concurrent является лучшим выбором, чем Hashtable с 1.5, но разрешит ли он проблему в этом случае? Или у вас есть другие предложения? –