Network Deployment (Distributed operating systems), v8.0 > Reference > Administrator best practices

Disable servlet pooling: Best practices and considerations

Overview

We may want to disable request and response pooling if...

• An application is creating threads inside of the application
• We are concerned about the web container reusing request and response objects.

Disable request and response pooling

• Application is creating threads inside of the application.

  The Servlet 2.4 specification states the following:

  SRV.4.10 Lifetime of the Request Object

  Each request object is valid only within the scope of a servlet’s service method, or within the scope of a filter’s doFilter method. Containers commonly recycle request objects in order to avoid the performance overhead of request object creation. The developer must be aware that maintaining references to request objects outside the scope described above is not recommended as it may have indeterminate results.

  SRV.5.6 Lifetime of the Response Object

  Each response object is valid only within the scope of a servlet’s service method, or within the scope of a filter’s doFilter method. Containers commonly recycle response objects in order to avoid the performance overhead of response object creation. The developer must be aware that maintaining references to response objects outside the scope described above may lead to non-deterministic behavior.

• If you are concerned about the web container reuse of reusing request and response objects. Since these objects are reused, there is the potential for two requests in two separate applications to have access to the same request or response object as described in the Thread Safety section of Servlet 2.4.

  SRV.2.3.3.3 Thread Safety

  Implementations of the request and response objects are not guaranteed to be thread safe. This means that they should only be used within the scope of the request handling thread.

  References to the request and response objects should not be given to objects executing in other threads as the resulting behavior may be nondeterministic. If the thread created by the application uses the container-managed objects, such as the request or response object, those objects must be accessed only within the servlet’s service life cycle and such thread itself should have a life cycle within the life cycle of the servlet’s service method because accessing those objects after the service method ends may cause undeterministic problems. Be aware that the request and response objects are not thread safe. If those objects were accessed in the multiple threads, the access should be synchronized or be done through the wrapper to add the thread safety, for instance, synchronizing the call of the methods to access the request attribute, or using a local output stream for the response object within a thread.

It is important to note that disabling pooling prevents the web container from recycling the servlet request and servlet response objects for subsequent requests. This creates additional overhead as a result of an increase in request and response object creation and the subsequent garbage collection of these discarded objects.
Modify the default web container configuration

+

Search Tips   |   Advanced Search