aspose file tools*
The moose likes Servlets and the fly likes ServletContext.setAttribute() always need Synchronization Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "ServletContext.setAttribute() always need Synchronization" Watch "ServletContext.setAttribute() always need Synchronization" New topic
Author

ServletContext.setAttribute() always need Synchronization

Alec Lee
Ranch Hand

Joined: Jan 28, 2004
Posts: 569
Should we always enclose getServletContext().setAttribute() around synchronized block? That means, is a single setAttribute() call thread-safe?
Jessica Sant
Sheriff

Joined: Oct 17, 2001
Posts: 4313

I would think that synchronizing ServletContext.setAttribute() would cause a HUGE bottleneck in your application. Typically information stored on the application level is stuff that is loaded once and the just read after that -- its rarely updated, mostly because of reasons you're concerned about.

I would avoid synchronizing on that call as best you can.
Alec Lee
Ranch Hand

Joined: Jan 28, 2004
Posts: 569
But is it correct to leave out the synchronization? In other words, is this method atomic? As far as I know, even modifying double and long primitive types are not guaranteed to be done atomically according to JVM spec!
Alec Lee
Ranch Hand

Joined: Jan 28, 2004
Posts: 569
If setAttribute() itself is not an atomic operation - we cannot assume yes because even something as simple as setting a primitive double type isn't guaranteed to be atomic - the consequence is that if there're 2 threads concurrently calling setAttribute(), the 2 calls could interfere with each other and result of one call PARTIALLY overwritten onto the result of second call.

What do you think?
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61653
    
  67

What do you think?


I'd think that your application design may need some re-thinking. As Jessica pointed out, putting things into application context is something that is usually done as part of app setup (when you don't need to worry much about threading) and then used throughout the app.

If the design of your app has scoped variables going in and out of application context at a rapid pace, it's probably a sign that you are using app context inappropriately.

If there is a section of code in which it necessary to modify application level scoped variables (such as refreshing a cached data structure from a database, to take an example from one of my apps), then the access points for that structure can be protected by synchronizing the critical sections.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Paul Bourdeaux
Ranch Hand

Joined: May 24, 2004
Posts: 783
Context attributes are not thread safe. In the case you described, you will need to synchronize in order to avoid problems. However, I agree with Bear - if you are doing a lot of updating to a context attribute during the life of an application, then you may need to look at some other way to pass that data around your application.


“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” - Rich Cook
Alec Lee
Ranch Hand

Joined: Jan 28, 2004
Posts: 569
It got nothing to do with my application's design. I am not using ServletContext as what you described, and I never mentioned that.

I just want to bring out a subtle issue that one may encounter in the future. Also, if ServletContext.setAttribute() has this issue then session.setAttribute() may also has. BTW, never assume sessions will not be accessed by multiple threads.
Paul Bourdeaux
Ranch Hand

Joined: May 24, 2004
Posts: 783
You are absolutely right. Neither context attributes nor session attributes are thread safe. Have you looked at the HF S&J book? In it they have a nice section talking about context/session attributes and thread safety.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61653
    
  67

I just want to bring out a subtle issue


It is an important issue and one that I don't think is a subtle issue at all. It's a well-established fact that these are not thread-safe. It's just been pointed out that if it's a real issue in your web app it may because of inappropriate use of the mechansims.
Rahul Bhattacharjee
Ranch Hand

Joined: Nov 29, 2005
Posts: 2308
Originally posted by Alec Lee:
Should we always enclose getServletContext().setAttribute() around synchronized block? That means, is a single setAttribute() call thread-safe?


ServletContext is only used to store some information that is required to be shared by the whole application.so there is hardly any need by the application for setting attribute to the context.as far as reading of the attributes (Objects) are concerned no need to put that in the sync. block.
If there is any requirement to write to the context then it would always be desirable to put that piece of code in the sync. block.

cheers!


Rahul Bhattacharjee
LinkedIn - Blog
Chidanand Chauhan
Ranch Hand

Joined: Nov 10, 2005
Posts: 77
I Think the above conversation is too much to understand the concept of ServletContext Attributes.

One thing which i want to tell you that only Request attributes are Thread Safe and Session and ServletContext Attributes are not Thread Safe.

If you want to use the ServletContext attribute then, you must use the synchronize block for accessng the attributes value otherwise the value will not come correct might be several thread are working on the same servletcontext or session attribute.
Similarly the session attributes are not thread safe because the same user uses the two browser and enter the two different value in the attribute then the value would be ambiguous what i suppose.
dema rogatkin
Ranch Hand

Joined: Oct 09, 2002
Posts: 294
I do not see any reason of using synchronization. Why should you worry about that? Object reference is atomic, so you can't read a reference which will point nowhere. I can see only one reason when you use lazy initialization and want to avoid a double or triple it. Check an approach I use in jAddresBook.


Tough in space?, <a href="http://tjws.sf.net" target="_blank" rel="nofollow">Get J2EE servlet container under 150Kbytes here</a><br />Love your iPod and want it anywhere?<a href="http://mediachest.sf.net" target="_blank" rel="nofollow">Check it here.</a><br /><a href="http://7bee.j2ee.us/book/Generics%20in%20JDK%201.5.html" target="_blank" rel="nofollow">Curious about generic in Java?</a><br /><a href="http://7bee.j2ee.us/bee/index-bee.html" target="_blank" rel="nofollow">Hate ant? Use bee.</a><br /><a href="http://7bee.j2ee.us/addressbook/" target="_blank" rel="nofollow">Need contacts anywhere?</a><br /><a href="http://searchdir.sourceforge.net/" target="_blank" rel="nofollow">How to promote your business with a search engine</a>
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: ServletContext.setAttribute() always need Synchronization