Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Servlet pooling

 
Ranch Hand
Posts: 109
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello ranchers,

in a EJB-container, there are pools for stateless session-beans,
entity-beans and message driven beans.

In a servlet-container, there is no pool for the servlets.
We only need one instance to service all of the requests.

I do not understand why the J2EE-components within the
EJB-container and servlet-container are handled differently.

Why is there a separate thread for every request
entertained by the same servlet instance instead
of using a servlet-pool?

There must be a reason for this different behaviour,
but I have no clue why EJBs are using a pool and
servlets do not.

Regards
Oliver
 
Rancher
Posts: 43016
76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
According to the servlet specification, a servlet container is free to pool servlets if it so wishes. Whether or not a particular container does so is up to its implementors.
 
Oliver Rensen
Ranch Hand
Posts: 109
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, but I still not understand, what is the advantage to serve all clients with only one instance compared to a servlet-pool?

To use a servlet-pool is not recommended, and some books like "Head First Servlets" do not even mention, that a servlet-pool is possible.
 
Ulf Dittmer
Rancher
Posts: 43016
76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

To use a servlet-pool is not recommended


Says who?

some books like "Head First Servlets" do not even mention, that a servlet-pool is possible.


I think that book is geared towards the SCWCD exam, und understanding the servlet spec. So it would make sense that it leaves out an advanced implementation-specific option like servlet pools.
 
Oliver Rensen
Ranch Hand
Posts: 109
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ulf, thanks for your help.
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Why is there a separate thread for every request
entertained by the same servlet instance instead
of using a servlet-pool?



1. Each request MUST have a separate Thread in order to manage the request and response objects.

2. If a pool of servlet objects was used, it would be very difficult to manage servlet instance variables.

Bill
 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A closer look in the Servlet spec reveals, that serlvet pooling only makes sense for servlets that implement the SingleThreadModel interface, which is deprecated.

The STM is slower than the Multithreaded approach, even if the STM servlets are pooled, since threads are easier to manage.

Just forget about the pool
[ October 11, 2007: Message edited by: Mladen Girazovski ]
 
Oliver Rensen
Ranch Hand
Posts: 109
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for the clarification.
 
Don't get me started about those stupid light bulbs.
    Bookmark Topic Watch Topic
  • New Topic