• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

performance using SingleThreadModel

 
Ranch Hand
Posts: 298
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Guys,
I have any of you used SingleThreadModel in this situation:
Suppose you have a servlet, or jsp document that creates many objects, initialises this objects, pass some parameters to these objects, than they do that processing returning some result needed to the page, in other words, this page uses lots of jsp actions (taglibs) and page scoped beans.
What do you think about notifing this page as SingleThreadModel (in servlets by implementing SingleThreadModel, in jsp pages by stating that the page isThreadSafe='false')? doing this, almost all containers will create instances of this page or servlet and pool them to the incoming requests. if we make these page scoped beans instance variables and make all initialization within jspInit() or init() methods do you think that this page creationg and pooling can make this page less havier than executing its service method, allocating memory for the beans, initializing these beans???
Thanks!
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I believe I have followed your argument and the answer is no - there is no good reason to use SingleThreadModel. You could end up creating the same number of page scoped beans as with the normal model and miss many chances to create objects that can be shared by all requests. Furthermore, object creation is not that big a perfomance hit in most cases - if you need objects that are expensive to create, use an object pool.
The SingleThreadModel is a leftover from the early days of servlets when people were still trying to make the mental jump from desktop-single user applications to the sevlet request-response/shared code model.
Bill
[ March 02, 2004: Message edited by: William Brogden ]
 
Leandro Oliveira
Ranch Hand
Posts: 298
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
suppose the objects are already created, and implementing object pooling will require more time than you have...
 
William Brogden
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Are these objects actually that expensive to create or are you just guessing? Do you have a complete example running so that you could actually measure some times?
I think there are plenty of examples of object pooling floating around that you could adapt.
Bill
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic