Проблема безопасности потока для сервлета

Question

Недавно я прочитал статью о написании поточно-безопасных сервлетов и узнал, что небезопасно использовать поля-члены сервлета в методах doGet() и doPost(), поскольку вполне вероятно, чтоодин экземпляр сервлета обрабатывает два отдельных запроса с двумя потоками, что означает, что переменные-члены являются общим ресурсом.Мне интересно, если я должен беспокоиться о безопасности потоков на зависимостях сервлетов.В моем проекте приложения сервлет будет вызывать сервисный обработчик сервиса POJO, и я думаю об одном внедрении зависимости от Spring (с использованием ApplicationContext.getBean()).Заранее спасибо.

Answer 1

Да, вы должны беспокоиться об этом и в POJO. Это переменная-член. Сделайте сервис безопасным.

Answer 2

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

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

Так просто:

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

getBean () является поточно-ориентированным, поэтому вы можете просто извлекать свои сервисы pojo и использовать их, если вы не сохраняете их как атрибуты сервлета.

В таком случае ваши единственные проблемы:

• бобы, живущие в сеансе;
• пользовательских кэшей;
• сложная пользовательская логика приложения;

Фасоль, живущая на сессиях, может быть неизменной (кроме случаев, когда применяются пункты 2 или 3). Пользовательские кэши обычно могут быть пропущены (во многих случаях они все равно не ускоряют работу - на самом деле! Если вы не можете доказать их полезность с помощью профилирования, отбросьте их). Это оставляет нас с номером 3: сложная логика приложения. А этот хитрый.

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