This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Thread safe Session, Context and Request?

 
Jehan Jaleel
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Are attributes placed in the Session, Context and Request thread-safe? One source I have said the container will make sure they are thread safe and another said it was developer's job.
Also does anyone know the difference when type attribute is used before class in UseBean action?
Thanks in advance for any help
 
Raj Paul
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi
only request attributes are thread safe in request,session,context.
type is used in useBean tag when u want cast the created object to parent class type.
<type> = (type) new class()
Raj Paul
 
Anthony Villanueva
Ranch Hand
Posts: 1055
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, only request attributes are thread-safe, since each service() thread has its own local request object.
The type attribute in
jsp:useBean usually designates a supertype of the bean.
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If memory serves, the servlet specification explicitly states that it is up to the developer to ensure that objects bound as ServletContext or HttpSession attributes are threadsafe. But even if it doesn't, you must assume multithreaded execution of such objects.
Notice that I didn't use the word "threadsafe". I feel the word "threadsafe" is misused here, and generally misused and misunderstood an awful lot on these forums. An object is either threadsafe, or it isn't. If it is threadsafe, this means that its behaviour is well-defined and its internal integrity is preserved when it is accessed by multiple threads simultaneously. If it isn't threadsafe, then it is unusable in a multithreaded environment. Merely binding an object in a place where no more than one thread will access it, such as a HttpRequest, DOES NOT MAKE IT A THREADSAFE OBJECT. Once you understand this, the isThreadSafe attribute of the JSP @page directive no longer seems so counterintuitive
If you get an exam question asking something along the lines of "is a JSP instance variable threadsafe", then the question is really whether the JSP would be threadsafe or not with an instance variable. In general it isn't, of course. Fortunately, you can set isThreadSafe to "false" so that the resultant servlet implements SingleThreadModel and the container will never run more than one request through it. Note that this doesn't make your JSP threadsafe, it just removes thread safety releated bugs from your application.
As regards the useBean tag, remember that (as Raj stated) the class attribute is primarily used for bean instantiation, whereas the type attribute is used for the runtime variable. I used this recently in a situation where I had an interface (let's call it FooBar) and I would normally expect to have an application-scoped implementation of this interface. However, under some error conditions, this would not be the case, so I used the class attribute to instantiate a dummy implementation if necessary:It goes without saying that these FooBar implementations were threadsafe; with four-CPU servers and an expected peak traffic in excess of 100 hits/second, you can be sure that any thread safety issue will show up sooner rather than later.
Hope this helps
- Peter
[ September 03, 2002: Message edited by: Peter den Haan ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic