Java servlets are making headlines these days, claiming to solve many of the problems associated with CGI and proprietary server API's. In this article Nakul describes the overall servlet architecture and what you need to develop a web application using servlets. He uses several coding examples to show you how to use the servlet API and compares it with CGI and proprietary server API's.
An Introduction to Java Servlets - Request attributes and resources (Page 9 of 10 )
The 2.1 version of the API adds two more mechanisms for sharing data between servlets: request attributes and resources.
The getAttribute, getAttributeNames and setAttribute methods were added to the HttpServletRequest class (or to be picky, the ServletRequest superclass). They are intended to be used ith the RequestDispatcher, an object that can be used to forward a request from one servlet to another and to include the output from one servlet in the output from the main servlet.
The getResource and getResourceAsStream functions in the ServletContext class gives you access to external resources, such as an application configuration file. You may be familiar with some methods that share the same names as these in the ClassLoader class. The ServletContext methods, however, can provide access to resources that are not necessarily files. A resource can be stored in a database, available through an LDAP server, in fact a resource is anything that the servlet engine vendor decides to support.
The servlet engine provides a context configuration option where you specify the root for the resource base, be it a directory path, an HTTP URL, a JDBC URL, etc.
Examples of how to use these methods may be the subject of a future article. Until then you can read about them in the Servlet 2.1 specification.
Multithreading
As you have seen above, concurrent requests for a servlet are handled by separate threads executing the corresponding request processing method (e.g. doGet or doPost). It's therefore important that these methods are thread safe.
The easiest way to guarantee that the code is thread safe is to avoid instance variables altogether and instead pass all information needed by a method as arguments. For instance:
is not safe. If the doGet method is executed by two threads, then it's likely that the value of the someParam instance variable will be replaced by the second thread while the first thread is still using it.
Here the processParam function gets all data it needs as arguments instead of relying on instance variables.
Another reason to avoid instance variables is that in a multi-server system, there may be one instance of the servlet for each server and requests for the same servlet may be distributed between the servers. Keeping track of information in instance variables in this scenario doesn't work at all. In this type of system you can instead use the HttpSession object, the ServletContext attributes, or an external data store such as a database or an RMI/CORBA service to maintain the application state. Even if you start out with a small single-server system, it's a good idea to write your servlets so that they can scale to a large, multi-server system the day you strike oil.