2

I'm using HttpSession object in Spring MVC with @Autowired:

public abstract class UserController {
    @Autowired
    public HttpSession session;

    @RequestMapping(value = { "" }, method = { RequestMethod.GET })
    public ModelAndView index(){
        User user=(User)session.getAttribute("loginUser");
    }
}

is the session thread-safe?

Jk1
  • 11,233
  • 9
  • 54
  • 64
snageyang
  • 59
  • 1
  • 6

1 Answers1

2

What you get wired from Spring is just the HttpSession. There are no special thread safety guarantees.

Implementations using HttpSession are not necessarily thread safe. See also this question: Is HttpSession thread safe, are set/get Attribute thread safe operations?

You could reduce the chances of race conditions causing problems without synchronization by:

  • reducing the chance that no two requests will be processed simultaneously for the session
  • not messing with the session from another thread than the request thread

If you need to process data from the session asynchronously, I find it is a better strategy to pull immutable objects from the session in the request thread and then use those in asynchronous processes on the server. That way you avoid access from the session as much as possible. That said, if you need to be totally safe (why take a risk), you need to synchronize.

synchronized(mutexFor(session)) {
  final String data = session.getAttribute("data");
  //do some work
  session.setAttribute("data", newValue);
}
Community
  • 1
  • 1
iwein
  • 25,788
  • 10
  • 70
  • 111
  • 2
    So, if you have parallel request threads, the session is thread-safe, but it becomes thread-unsafe if the parallel thread is not a request thread? That makes no sense. The session is thread-safe. What could be thread-unsafe is the objects that are stored in the session. – JB Nizet Dec 31 '12 at 07:57
  • @JBNizet your interpretation makes no sense indeed, I've changed the wording to avoid that. To be clear, HttpSession is an interface, so the implementation is what could be thread safe or not. Some operations are guaranteed to be thread-safe by the spec, but not all implementations comply with that. See also: http://stackoverflow.com/questions/616601/is-httpsession-thread-safe-are-set-get-attribute-thread-safe-operations – iwein Dec 31 '12 at 08:53
  • The spec says: "The container must ensure that manipulation of internal data structures representing the session attributes is performed in a thread safe manner. The Developer has the responsibility for thread safe access to the attribute objects themselves". So the session is thread-safe. Of course, as the IBM article you linked to explains, that doesn't make programs using it automatically thread-safe. But that's the case of every thread-safe object. – JB Nizet Dec 31 '12 at 15:59
  • You are correct @JBNizet, do you agree with the answer as it is now? – iwein Dec 31 '12 at 17:24
  • Not really actually, but I'll remove my downvote. When it comes to correctness, you don't "reduce the chance of concurrency bugs". You carefully design and program to make your code correct, by understanding what you're doing. – JB Nizet Dec 31 '12 at 17:27