File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Servlets and the fly likes Synchronizing session Object Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "Synchronizing session Object" Watch "Synchronizing session Object" New topic

Synchronizing session Object

Ankur Luthra
Ranch Hand

Joined: Dec 13, 2010
Posts: 39
Hi ,
Pardon me for my lack of knowledge .I had a query and wanted to discuss with fellow ranchers.

Does the above code
a) Synchronize mySession object ?
b) Do we even need the synchronized block.As each request goes as a new thread.

Can anyone clarify this doubt?

Jelle Klap

Joined: Mar 10, 2008
Posts: 1951

Well, according to the servlet specification (v3.0, paragraph 7.7.1):

Multiple servlets executing request threads may have active access to the same session object at the same time. 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. This will protect the attribute collection inside the HttpSession object from concurrent access, eliminating the opportunity for anapplication to cause that collection to become corrupted.

So thread-safety of getAttribute() / setAttribute() calls should be guarenteed by the container, but thread-safe manipulation of the attribute itself is up to you.
In your case simply setting an immutable object as an attribute should be safe, regardless of additional synchornization - the synchonized block is not necessary.
If you were to get, modify and set a mutable object it would be a different matter, and synchronizing on the HttpSession instance might not be good enough in that case.
I don't believe there's any restriction specifying that a container must provide the same HttpSession instance for the same session(id) - though in practice I guess most containers probably do.

Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 17417

getSession(false) can return null, which would have unfortunate consequences when the "synchronized" statement was executed. This is based on what Murphy's Law says will happen, not what is "supposed" to happen.

You would not normally synchronize at the session level, because each user has a session independent from every other user, except in cases where the user doesn't have a session at all (see above!).

So more commonly you would synchronize at application scope, and only worry about session-scope synchronization in cases where overlapping requests for the same user likely to occur. At human speeds, doing human workflows, that's rarely a problem, so mostly it would be automated clients that would be at risk.

An IDE is no substitute for an Intelligent Developer.
I agree. Here's the link:
subject: Synchronizing session Object
It's not a secret anymore!