CODEWITHSUNDEEP
javaservletsthread-safety
user1622048
user1622048

Reputation: 23

Detailed Thread-Safety Questions concerning Java Servlets

I currently have to make a specific Java servlet implementation thread-safe. The code is not written by me and I wasn't involved in it's design or anything. I "just" have to make it thread-safe :)

I'm not a beginner in thread-safety, but not a professional either. Servlets are (more or less) completely new to me. I've worked through some tutorials and know the basics about servlets, but that's it. All tutorials I could find about making servlets thread-safe were rather superficial and I still have some unanswered questions which I just can't seem to find answers for. Some help would be much appreciated.

1.) From what I understand, HttpServletRequests and HttpServletResponses are not shared between different threads, so I don't need to synchronize read- and write access on them (is this correct?). But what about HttpServletRequestWrappers etc.?

2.) I have to synchronize access to the ServletContext object returned by getServletContext(), especially if I use setAttribute() on it, right?

3.) HttpServletRequests has a getCookies() method. Are these Cookies potentially shared between different requests or does every request have it's own Cookie objects (even if they represent the same "real" cookie)? Asked differently: Do I have to synchronize the access to the returned cookie objects?

Thanks for taking time to read my questions. I'm looking forward to your answers :)

Upvotes: 2

Views: 3056

Answers (3)

Nandkumar Tekale
Nandkumar Tekale

Reputation: 16158

  1. Your understanding is correct. Actually thread is created for each request. So HttpServletRequest and HttpServletResponse are local to thread. So no sharing of these two. You do not need to synchronize them. HttpServletRequestWrapper and HttpServletResponseWrapper are the classes which provide a convenient implementation of the HttpServletRequest and HttpServletResponse interfaces respectively. You do not need to worry about them in synchronization context.

  2. Definitely you have to provide synchronization for ServletContext object returned by getServletContext() because it is shared between servlets in your application.

  3. As HttpServletRequest is local to thread created by container to serve the request. So cookies are also local to that thread and those are not shared. So no need to provide synchronization to cookies.

Few concepts :

  1. Servlets are always singlton in your application. i.e. only one object is created.
  2. For each request a different thread is created(actually obtained from Thread Pool). Following things are local to thread : HttpServletRequest, HttpServletResponse

Upvotes: 1

palto
palto

Reputation: 3583

When you make servlets thread safe, you rarely need synchronization. Servlets should also be thread safe from the beginning because single instance of servlet might be used by multiple users. In addition you cannot trust that there will just be one instance of a servlet, unless your servlet container specifies that there will always be just one.

1) No need for synchronization when dealing with request and response objects because only one thread can handle a request at a time.

2) You should try to design your application in a way that you don't have to set any values in ServletContext inside a servlet. Usually ServletContext is initialized in the startup and then used as read only by servlets or filters. I'm not exactly sure if it is supposed to be thread safe, but you have to synchronize anyways if you set multiple values in same request so the servlets reading those values don't get messsed up. But that is basic thread safety issue and doesn't specifically have to do with servlets.

3) No need for synchronization for cookies because they deal with the current request and only one thread can do it.

New servlet containers allow for asynchronous model where multiple threads might handle a single request but it is still one thread at a time.

Upvotes: 2

Vikdor
Vikdor

Reputation: 24124

Servlets are not thread safe because the application server can maintain a single instance of the servlet or a pool of instances and share them across multiple incoming requests. And hence, servlets should not have any state (i.e servlet object level variables are not thread-safe). Servlet specification used to have SingleThreadModel interface earlier to enforce a given servlet to be thread-safe but that's been deprecated since 2.3, I guess.

Responses:

  1. Right, these are paramters to the HTTP methods like doGet and doPost and hence accesses to these need not be synchronized.

  2. Right because getServletContext() returns a context level object that is accessible to all servlets and all threads running a given servlet.

  3. Every request comes with its own set of cookies. Again, this is obtained fromt the method parameter, HttpServletRequest and so accesses need not be synchronized.

Upvotes: 2

Related Questions