• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Paul Clapham
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Roland Mueller
  • Piet Souris
Bartenders:

Doubt on attribute scope thread saftey mock Q

 
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
HI,


Which of the following attribute scopes are thread-safe? [Check all correct answers]

1. Request attribute.

2. Response attribute.

3. Session attribute.

4. Context attribute.

5. None of the above.




The Answer is 1.) and 2.)


The spec defines three scope, Application, Session and Request scope .. I dont undertand why option 2.) Response Attribute is right.

When object is to be made available to target, the object is sent in the request scope.


Thanks,
Reshma
 
Author
Posts: 836
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I dont undertand why option 2.) Response Attribute is right.

Neither do I, since there are no such things as "response attributes"! I think this was a mistake in the question (perhaps that option was meant to fool you, and yet they accidentically gave it as a correct answer).

The only thread-safe scopes are request and page (for JSPs). Session and context attributes are by default not guarded against concurrent access, so synchronisation on the session or context objects is recommended when there is the possibility for a simultaneous multiple modification or concurrent retrieval and modification.
 
Reshma Shanbhag
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for help Charles. I feel good with my preparations reading your reply.

Reshma
 
Ranch Hand
Posts: 951
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Charles,

You are considering Request Attribute as thred-safe. Though it sounds fesible, I think the request attributes are not thread safe, as there my be references to the attributes object through which we can make changes to the attribute object.

The request Object is thread-safe as they pass as the method parameters.

Please Comments.

Thanks
 
Ranch Hand
Posts: 256
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with Narendra, this is what specifications says

SRV.2.3.3.3 Thread Safety
Implementations of the request and response objects are not guaranteed to be thread safe. This means that they should only be used within the scope of the request handling thread.
References to the request and response objects should not be given to objects executing in other threads as the resulting behavior may be nondeterministic. If the thread created by the application uses the container-managed objects, such as the request or response object, those objects must be accessed only within the servlet�s service life cycle and such thread itself should have a life cycle within the life cycle of the servlet�s service method because accessing those objects
after the service method ends may cause undeterministic problems. Be aware
that the request and response objects are not thread safe. If those objects were accessed in the multiple threads, the access should be synchronized or be done through the wrapper to add the thread safety, for instance, synchronizing the call of the methods to access the

request attribute

, or using a local output stream for
the response object within a thread.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic