Java EE Servlet - Должен ли я синхронизировать каждый доступ к области приложения?

Question

Я видел очень интересное сообщение here, похоже, что люди в ASP.NET должны синхронизировать свой доступ к области приложения, поэтому мне было интересно, имеют ли те же самые ограничения, которые развивают технологию Java EE JSP/Servlet.

Вот пример:

public class MyServlet extends HttpServlet { 
    private static Lock applicationScopeLock = new ReentrantLock();   

    @Override 
    public void doPost(HttpServletRequest request, HttpServletResponse response){ 
     applicationScopeLock.lock(); 
     try { 
      ServletContext appScope = this.getServletContext(); 
      appScope.setAttribute("myKey", new MyValue()); 
     } finally { 
      applicationScopeLock.unlock(); 
     } 
    } 

1. Требуется ли синхронизация для манипулирования области применения в технологии/Servlet JSP?
2. Если да, следует ли использовать синхронизацию (locks) для setAttribute(), а также getAttribute() или setAttribute() достаточно?

Спасибо.

EDIT:

Я видел подобную тему с более подробной here². Чтобы поднять Servlet Specification 3.1 (read §4.5), только говорят, что атрибуты в контексте могут быть разделены между различными сервлетами в одном и том же веб-приложении, но явно не говорят, являются ли setAttribute/getAttribute потоковыми (ни Javadoc). Некоторые контейнеры сервлетов, такие как Tomcat, используют реализацию ConcurrentHashmap (но это не входит в спецификацию). В заключение я также прочитал, что хорошей практикой является использование неизменяемых/потокобезопасных объектов для значений.

Answer 1

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

2. Я бы пошёл для обоих, просто чтобы быть в безопасности. Я даже советую вам обернуть весь блок, имея дело с модификацией объекта, хранящегося в контексте приложения, в синхронизированном блоке. Я также попытался бы использовать этот контекст как можно меньше, поскольку он приносит много накладных расходов, и если он не будет осторожен, это может вызвать проблемы.