Storing Application-Wide Data

The HttpSession class stores data items on a per-user basis. Sometimes, however, you have data that you need to share between various servlets and JSPs that doesn't need to be stored for each user. For example, if you are writing a database application, you might need to share a database connection. From a JSP, you can store data in the application object. The methods for storing data in the application object are identical to the ones for the session object:

public void setAttribute(String name, Object value)
public Object getAttribute(String name)
public void removeAttribute(String name)

From a JSP, if you want to store information in the application object under the name "myInformation," you make a call such as this:

application.setAttribute("myInformation", "Here is the info");

To get the information back out of the application object, you call getAttribute:

String theInfo = (String) application.getAttribute("myInformation");

The application object is really an object that implements the ServletContext interface. The servlet context is also available from within the servlet. If your servlet is a subclass of GenericServlet or HttpServlet, as most are, you can call the getServletContext method:

ServletContext context = getServletContext();
context.setAttribute("myInformation", "Here is the info");

Remember that your servlet doesn't have to be a subclass of GenericServlet or HttpServlet. You can choose to write your own class that implements the Servlet interface. If you need to get hold of the servlet context in these cases, the context is contained in the ServletConfig object that is passed to your servlet's init method. You can always call getServletConfig().getServletContext() to get the servlet context.

Why You Need the application Object

From all appearances, the application object seems like overkill. What is the difference between storing something in the application object and storing it in a static variable somewhere?

The servlet engine knows to what application a particular JSP or servlet belongs. You can, for example, have a set of JSPs deployed in a server under an application called QA and an identical set of JSPs under an application called Beta. These two applications, although running in the same server and the same JVM, would have different application objects (that is, different ServletContext objects).

Now you can see how the application object differs from a static variable. If you tried to store a data item in a static variable, you would circumvent the notion of separate applications. There is only one copy of a static variable within a single JVM. You can't say that the QA application gets its own copy of a static variable and the Beta application gets another unless you are somehow able to run each application in a separate virtual machine. Because you can't count on a servlet engine to support multiple JVMs, you shouldn't rely on static variables for application-level data sharing.

You have also seen in previous hours that you can store application configuration information in the application object that is available to all JSPs and servlets in the Web application. This configuration information comes from the web.xml file that you create when you package your application in a WAR file.