0

I saw a very interesting message here, it looks like people in ASP.NET have to synchronize their access to application scope, so I was wondering if people who develop in Java EE JSP/Servlet technology have also the same constraint.

Here an example :

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. Is synchronization required for manipulating application scope in JSP/Servlet technology ?
  2. If yes, should I use synchronization (locks) for setAttribute() and also getAttribute(), or setAttribute() is enough ?

Thanks.

EDIT:

I saw a similar topic with more details here². To sump up Servlet Specification 3.1 (read §4.5) only say that attributes in a context may be shared between different servlets in the same Web application, but doesn't explicitely say if setAttribute/getAttribute are threadsafe (neither Javadoc). Some servlet containers like Tomcat use ConcurrentHashmap implementation (but it's not part of the specification). To conclude I have also read that a good practice is to use immutable/threadsafe objects for values.

Community
  • 1
  • 1
gokan
  • 1,028
  • 1
  • 14
  • 30
  • I think that this so close to a duplicate that it makes no difference. Certainly the reasoning in the linked question applies. – Stephen C Jul 26 '15 at 01:03

1 Answers1

-3

  1. The short answer is yes. This is due to the fact, that each incoming request to the server is handled in a different thread. Since the application context is shared for all requests, this means it may be accessed in a concurrent way.

  2. I would go for both, just to be on the safe side. I will even advice you to wrap the whole block, dealing with modifying an object, stored in the application context, in a synchronized block. I would also try to use this context as little as possible, since it brings a lot of overhead and, if one is not careful, it can cause problems.

Danail Alexiev
  • 7,624
  • 3
  • 20
  • 28
  • Someone gave you "-1" (not me), I don't undestand why because your answer seems logical. – gokan Jul 26 '15 at 00:11
  • It is only logical if you ignore the context. The context is that while a servlet stack where these operations weren't thread-safe *might be* compliant to the letter of the spec, most programmers would call it BROKEN. Besides, you don't need to make assumptions. Look at the source code. – Stephen C Jul 26 '15 at 01:07
  • There is nothing in the spec that enforces the immutability of the objects, being stored, or the thread - safety of the implementation. Since there was no concrete example, I assumed the worst case - that the object in question are mutable, and, if they indeed are, they access to them should be serialized. I also agree that immutable is the way to go, but I don't see why my answer is considered incorrect. – Danail Alexiev Jul 26 '15 at 13:41