1) ServletContext - So all servlets may access the same data
2) Session - User specific state
3) Servlet - resources that are of value only to that servlet.
4) static variables - Available to any class in the classloader. The most dangerous way to maintain state but sometimes a needed evil.
The original intent was to have servlets allocated objects and multiple requests each hit the same servlet instance. I would imagine there was an intent to allow admins to configure a servlet to allow for a maximum number of concurrent requests flowing into the same servlet instance at one time. If the limit was reached - new instances would be created. In reality, no one implemented it because it was pretty stupid. Its much easier to have all request got through the same instance and let the servlet worry about the shared resource issues.
-Tim
Keith Hankin wrote:
Maybe I'm being dumb, but it seems to me that based upon what I'm hearing, there is no benefit of doing Servlet instance pooling since the Servlets aren't true objects; they are merely places to put code, since no local state is useful.
----- Original Message ----- From: "Shapira, Yoav" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Wednesday, June 16, 2004 7:06 PM Subject: RE: Multiple requests sharing the same Servlet instance
Hi,
But if a Servlet instance might be used by multiple threads at one
time,
then what's the point of having Servlet object pooling at all? Why
wouldn't
It might and it might not. My point was that the Servlet Spec leaves it for the container implementation to decide, and so you should be careful.
all requests just use one instance? I still don't see how I can have variables that are just for storing a single thread's working data. The
You can do so easily inside any method, or in ThreadLocal variables, or in request-scope attributes, or in other non-servlet object pools that you write (or use a 3rd party pooling library). The ways are plentiful and except for the request attributes they're not specific to servlet containers (nor is this issue in general specific to servlet containers).
way I can do anything like this is to attach attributes to the request.
But
this seems to be a kludge to me. I don't want to have to use Strings to
get
to my data by way of a Map. I want regular Java local variables.
Address your comments, suggestions, etc. to the Servlet Specification JSR team (it's JSR154). I'm just telling you what the spec guarantees and what it doesn't ;)
Yoav
This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
