• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

ServletContext.setAttribute() always need Synchronization

 
Alec Lee
Ranch Hand
Posts: 569
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Should we always enclose getServletContext().setAttribute() around synchronized block? That means, is a single setAttribute() call thread-safe?
 
Jessica Sant
Sheriff
Posts: 4313
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 569
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 569
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 65129
92
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Paul Bourdeaux
Ranch Hand
Posts: 783
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Alec Lee
Ranch Hand
Posts: 569
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 783
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 65129
92
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
Chidanand Chauhan
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 294
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic