Sometimes a servlet is unable to complete the processing of a request without waiting for a resource or event before generating a response. For example, a servlet may need to wait for an available JDBC connection, for a response from a remote web service, for a JMS message, or for an application event, before proceeding to generate a response. Waiting within the servlet is an inefficient operation as it is a blocking operation that consumes a thread and other limited resources.

Servlet 3.0 introduces the ability for asynchronous processing of requests so that the thread may return to the container and perform other tasks. When asynchronous processing begins on the request, another thread or callback may either generate the response and call complete or dispatch the request so that it may run in the context of the container using the AsyncContext.dispatch() method as shown below:

REQUEST to /url/A

FORWARD to /url/B

getRequestDispatcher(“/url/B”).forward(request, response);

AsyncContext ac = request.startAsync();

ac.dispatch(); //does a ASYNC dispatch to /url/A

Servlet 3.0 specification introduced several new features like ease of development through annotations, Pluggability and extensions support for adding third party framework and asynchronous processing that made Servlet development easy and simple.

The features are:

• • Ease of development using Annotations – Servlets are configured using xml elements in web.xml, from Servlet 3.0 it is also possible to specify the Servlet definition in the component itself, through annotations. Annotations – @WebServlet, @WebServletContextListener, @ServletFilter, @InitParam helps to define Servlet.

• • Pluggability through Web Frameworks –  Pluggability provides fewer configurations and a good modularity for web applications. Pluggability is achieved with the introduction of web module deployment descriptor fragments, shortly referred as ‘web fragments’. A web fragment is part of web.xml that is specified and included in the framework specific jars META-INF directory.

• • Asynchronous Processing in Servlet – In many situations, Servlet has to interact with a resource for processing data– it could be database resource, a web service or a message resource.  While interacting with these resources, the Servlet has to wait until it gets a response from the resource before it actually generates a response. This makes the Servlet call to the resource as a blocking call and results in the inefficiency of the Servlet response. Servlet 3.0 specification addresses this issue of Servlet thread being blocked with the introduction of asynchronous processing of Servlet. This asynchronous processing allows the thread to issue a call to the resource and return back to the container without getting blocked so that it can perform other tasks which results in the increase in efficiency of Servlet performance.

Filters can be used for the following:

• Authentication filters
• Logging and auditing filters
• Image conversion filters
• Data compression filters
• Encryption filters
• Tokenizing filters
• Filters that trigger resource access events
• XSL/T filters that transform XML content
• MIME-type chain filters
• Caching filters

A filter is defined either via the @WebFilter annotation or in the deployment descriptor using the <filter> element. In this element, the following elements are used:

• filter-name: used to map the filter to a servlet or URL
• filter-class: used by the container to identify the filter type
• init-params: initialization parameters for a filter

The container will instantiate exactly one instance of the Java class defining the filter per filter declaration in the deployment descriptor.

Here is an example of a filter declaration:

<filter>

 <filter-name>LoggingFilter</filter-name>

 <filter-class>com.demo.LoggingFilter</filter-class>

</filter>

Once a filter has been declared in the deployment descriptor, the <filter-mapping> element is used to define servlets and static resources in the Web application to which the filter is to be applied

<filter-mapping>

 <filter-name>LoggingFilter</filter-name>

 <url-pattern>/*</url-pattern>

</filter-mapping>

Here the Logging Filter is applied to all the servlets and static content pages in the Web application, because every request URI matches the ‘/*’ URL pattern.

A filter is a servlet that can transform the content of HTTP requests, responses, and header information. Filters do not generally create a response or respond to a request as servlets do, rather they modify or adapt the requests for a resource, and modify or adapt responses from a resource. Filters can act on dynamic or static content.

Filters are typically used for the following:

• Accessing of a resource before a request to it is invoked.
• Processing of the request for a resource before it is invoked.
• Modification of request headers and data by wrapping the request in customized versions of the request object.
• Modification of response headers and response data by providing customized versions of the response object.
• Interception of an invocation of a resource after its call.
• Actions on a servlet, on groups of servlets, or static content by zero, one, or more filters in a specifiable order.

An existing session can be destroyed in the following ways:

• Programmatically : Using session.invalidate() method, which makes the container abandon the session on which the method is called.
• When the server itself is shutdown.
• Setting timeout in the deployment descriptor: This can be done by specifying timeout between the <session-timeout>tags.
• Setting timeout programmatically: This will set the timeout for a specific session.

Session represents a conversional state between client and server and it can consists of multiple request and response between client and server. Since HTTP is stateless, the only way to maintain a session is when some unique information about the session (session id) is passed between server and client in every request and response. Session can be handled in Servlet using one of the following techniques:

• HTML Hidden Form Fields
• Cookies
• URL Rewriting
• Session Management API

The RequestDispatcher include() method inserts the contents of the specified resource directly in the flow of the servlet response, as if it were part of the calling servlet. The include() method is often used to include common “boilerplate” text or template markup that may be included by many servlets.

The RequestDispatcher forward() method is used to show a different resource in place of the servlet that was originally called. The forward() method is often used where a servlet is taking a controller role; processing some input and deciding the outcome by returning a particular response page.

RequestDispatcher forward() is used to forward the same request to another resource whereas ServletResponse sendRedirect() is a two-step process. In sendRedirect(), web application returns the response to client with status code 302 (redirect) with URL to send the request. The request sent is a completely new request.

The forward() is handled internally by the container whereas sendRedirect() is handled by browser. We should use forward() when accessing resources in the same application because it’s faster than sendRedirect() method that required an extra network call.

In forward() browser is unaware of the actual processing resource and the URL in address bar remains same whereas in sendRedirect() URL in address bar change to the forwarded resource. The forward() can’t be used to invoke a servlet in another context, we can only use sendRedirect() in this case.

The init() method and destroy() method of a HttpServlet are called only once in the Servlet life cycle. But the service methods such as doGet() or doPost() are getting called for every client request and since servlet uses multithreading, we should provide thread safety in these methods.

To make sure that a servlet is thread safe, the service() method should not access any member variables, unless these member variables are thread safe themselves. The service() method should not reassign member variables, as this may affect other threads executing inside the service() method. If there is a compelling need to reassign a member variable, make sure this is done inside a synchronized block. If there are any local variables in service methods, no need to worry because local variables are always thread safe.