JavaSercer Pages Let’s review how placing the bean in the request scope lets you access the same bean in all pages. The user first requests the userinfoinput.jsp page (Example 8.1). A new instance of the userInfo bean is created in the request scope and used to generate the “enter all fields” status message. The user fills out the form and submits it as a new request to the userinfovalidate.jsp page (Example 8.2). The previous bean is then out of scope, so this page creates a new userInfo bean in the request scope and sets all bean properties based on the form field values. If the input is invalid, the action passes the control back to the userinfoinput.jsp page. Note that we’re still processing the same request that initially created the bean and set all the property values. Since the bean is saved in the request scope, the action finds it and uses it to generate an appropriate error message and fill out the form with any valid values already entered. 8.2 Sharing Session and Application Data As described in Chapter 2, HTTP is a stateless, request-response protocol. This means that the browser sends a request for a web resource, and the web server processes the request and returns a response. The server then forgets this transaction ever happened. So when the same browser sends a new request, the web server has no idea that this request is related to the previous one. This is fine if you’re dealing with static files, but it’s a problem in an interactive web application. In a travel agency application, for instance, it’s important to remember the dates and destination entered to book the flight so the customer doesn’t have to enter the same information again when it’s time to make hotel and rental car reservations. The way to solve this problem is to let the server send a piece of information to the browser that the browser then includes in all subsequent requests. This piece of information, called a session ID, is used by the server to recognize a set of requests from the same browser as related: in other words, as part of the same session. A session starts when the browser makes the first request for a JSP page in a particular application. The session can be ended explicitly by the application, or the JSP container can end it after a period of user inactivity (the default value is typically 30 minutes after the last request). Thanks to the session ID, the server knows that all requests from the same browser are related. Information can therefore be saved on the server while processing one request and accessed later when another request is processed. The server uses the session ID to associate the requests with a session object, a temporary in- memory storage area where servlets and JSP pages can store information. The session ID can be transferred between the server and browser in a few different ways. The Servlet 2.2 API, which is the foundation for the JSP 1.1 specification, identifies three methods: using cookies, using encoded URLs, and using the session mechanism built into the Secure Socket Layer (SSL), the encryption technology used by HTTPS. SSL-based session tracking is currently not supported by any of the major servlet containers, but all of them support the cookie and URL rewriting techniques. JSP hides most of the details about how the session ID is transferred and how the session object is created and accessed, providing you with the session scope to handle session data at a convenient level of abstraction. Information saved in the session scope is available to all pages requested by the same browser during the lifetime of the session. However, some information is needed by multiple pages independent of who the current user is. JSP supports access to this type of shared information through another scope, the application scope. Information saved in the application scope by one page can later be accessed by another page, even if the two pages were requested by different users. Examples of information typically shared through the application scope are database connection pool objects, information about currently logged-in users, and cache objects to avoid frequent database lookups. page 92
Quick Hint: If you are looking for cheap and reliable provider to host and run your servlet application check Vision servlet hosting plans
This entry was posted
on Wednesday, December 13th, 2006 at 9:09 pm and is filed under Java.
You can follow any responses to this entry through the RSS 2.0 feed.
Responses are currently closed, but you can trackback from your own site.