This week's book giveaway is in the Performance forum.
We're giving away four copies of The Java Performance Companion and have Charlie Hunt, Monica Beckwith, Poonam Parhar, & Bengt Rutisson on-line!
See this thread for details.
Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Synchronizing session Object

 
Ankur Luthra
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?

Regards,
Ankur
 
Jelle Klap
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Tim Holloway
Saloon Keeper
Pie
Posts: 18212
53
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic