Like most people preparing for SCWCD, I too am following the excellent resource - Head First Servlets & JSP 2nd Edition.
I have a doubt regarding one of the concepts presented on pages 95 and 96.
On page 95, 2nd and 3rd steps, it is described that the container creates the Request and Response objects BEFORE creating/allocating a thread for the request that the Request and Response objects belong to.
Then on page 96, 6th step states that after the thread dies or returns to a Container-managed thread pool, the Request and Response object references fall out of scope.
My doubt is - if the container is responsible for the creation of Request and Response objects, and obviously has a reference to them, then why do they fall out of scope on the completion of the thread to which their references are passed?
Chinmaya Chowdary wrote:Hi, Ravi. I think when a request comes, the container creates request and response object directly in the service method like service(new HttpServletRequestImpl(), new HttpServletResponseImpl()), not creating like HttpServletRequest request=new HttpServletRequestImpl() and HttpServletResponse response=new HttpServletResponseImpl() and pass to service(request, response).
Thanks a ton for your reply but that doesnt solve my doubt. The question is, how can two objects created before the creation of a thread, fall out of scope on the completion of that thread.
Hope this helps
Zaheer A Baloch wrote:When the webcontainer gets a requests it creates Request and Response objects. Then creates a thread for the servlet being requested and then passes the objects to service method of servlet. When the service method completes, the web container sends the response back. After that request and response objects are destroyed. Note that service method gets the objects as parameters and its job of container to create and destroy these objects.
Hope this helps
You are merely quoting whats mentioned in the book. I understand that. I know its the way its supposed to work. But my issue is with the line where the authors mention - the request and response objects fall out of scope on completion of the thread, which does not make sense to me. The language implies that somehow completion of the thread makes these objects fall out of scope, while I believe its the container that decides when to remove references to those objects and make them available for Garbage Collection. So probably instead of " The service() method completes,so the thread either dies or returns to a Container-managed thread pool. The request and response object references fall out of scope, so these objects are toast (ready for garbage collection)." it could have been - "The service() method completes,so the thread either dies or returns to a Container-managed thread pool. The container destroys any references to request and response objects and thus they fall out of scope and become available for garbage collection."
ravi gupta wrote:... the request and response objects fall out of scope on completion of the thread, which does not make sense to me. The language implies that somehow completion of the thread makes these objects fall out of scope, while I believe its the container that decides when to remove references to those objects and make them available for Garbage Collection.
It might be that the container doesn't hold any references to these objects:
When the method ends, the req & resp varibles are out of scope, but your service/doGet method is keeping them "alive". When you exit your service() method, these objects are not referred by anything - so are GCed.
What I'm saying is that it is possible to not keep references to req&resp objects after the service method exits.
I bet you won't be asked something like this in the exam.