In case of servlet, it keeps running even after a request is executed. How does servlet keep running after a request is executed ? Whats the mechanism that keeps it running ?
You, as the developer, don't have to write an ounce of thread-creation code because the app server does it for you. In fact, if your servlet doesn't have any member variables or share objects across the application you wouldn't even have to think about concurrency.
Except many servlets do evolve to share something, which is when things get ugly pretty quickly and coders have to tread far more cautiously.
Bear Bibeault wrote:Indeed. There are circumstances where more than one instance of a servlet can be loaded, but that has no bearing on how Servlets need to be written in a thread-safe manner.
If you don't use servlet attributes and/or only use final attributes then you don't have threading issue. But if you do use servlet attributes and manipulate these attributes within the service method then you do have to worry or should consider changing your design.
Duc Vo wrote:If you don't use servlet attributes and/or only use final attributes then you don't have threading issue.
Huh? What are "servlet attributes"?
If you are talking about instance variables, then yes, that's my entire point. Servlets must be written in a thread-safe manner.
Ryan Beckett wrote:I am well aware that only local variables and request attributes are thread safe. What is a scenario that would allow multiple instances of a servlet to be loaded?
The same servlet class can be declared multiple times in the deployment descriptor, and each will cause a servlet instance to be loaded. Additionally, the servlet specification allows for the container to decide to instantiate as many instances as it would like based upon its internal implementation details.