Home | E-mail 

Exam Notes for the Sun Certified Web Component Developer (SCWCD) Exam

5. Designing and Developing Servlets Using Session Management

5.1. Identify the interface and method for each of the following:

5.1.1. retrieve a session object across multiple requests to the same or different servlets within the same webapp
5.1.1.1. public HttpSession HttpServletRequest.getSession([boolean create])
5.1.1.2. if no argument provided, then server will automatically create a new session object if none exists for the user in the web app context
5.1.1.3. to make sure the session is properly maintained, getSession must be called at least once before committing the response
5.1.1.4. sessions are scoped at the web application level; so a servlet running inside one context cannot access session information saved by another context.
5.1.1.5. behind the scenes, the client's session id is usually saved on the client in a cookie called JSESSIONID. For client that don't support cookies, the session ID can be sent as part of a rewritten URL, encoded using a jsessionid path parameter.
5.1.1.6. note that a requested session id may not match the id of the session returned by the getSession() method, such as when the id is invalid. one can call req.isRequestedSessionIDValid() to test if the requested session id (that which was defined in the rewritten url or the persistent cookie) is valid.
5.1.2. store objects into a session object
5.1.2.1. public void HttpSession.setAttribute(String name, Object value) throws IllegalStateException
5.1.2.2. binds the specified object under the specified name. Any existing binding with the same name is replaced.
5.1.2.3. IllegalStateException thrown if session being accessed is invalid
5.1.3. retrieve objects from a session object
5.1.3.1. public Object HttpSession.getAttribute(String name) throws IllegalStateException -- returns the object bound under the specified name or null if there is no binding
5.1.3.2. public Enumeration HttpSession.getAttributeNames() throws IllegalStateException -- returns all bound attribute names as an enumeration of Strings (empty enum if no bindings)
5.1.3.3. public void HttpSession.removeAttribute(String name) throws IllegalStateException -- removes binding or does nothing if binding does not exist
5.1.4. respond to the event when a particular object is added to a session
5.1.4.1. any object that implements the javax.servlet.http.HttpSessionBindingListener interface is notified when it is bound to or unbound from a session.
5.1.4.2. public void valueBound(HttpSessionBindingEvent event) is called when the object is bound to a session
5.1.4.3. public void valueUnbound(HttpSessionBindingEvent event) is called when the object is unbound from a session, by being removed or replaced, or by having the session invalidated
5.1.5. respond to the event when a session is created or destroyed: see section 3.5
5.1.6. expunge a session object
5.1.6.1. public void HttpSession.invalidate() - causes the session to be immediately invalidated. All objects stored in the session are unbound. Call this method to implement a "logout".

5.2. given a scenario, state whether a session object will be invalidated

5.2.1. ideally, a session would be invalidated as soon as the user closed his browser, browsed to a different site, or stepped away from his desk. Unfortunately, there's no way for a server to detect any of these events.
5.2.2. session may expire automatically, after a set timeout of inactivity (tomcat default is 30 minutes)
5.2.3. timeout can be overridden in web.xml file by specifying <web-app>…<session-config><session-timeout>e.g. 60</session-timeout></session-config> </web-app>
5.2.4. timeout can be overridden for a specific session by calling HttpSession.setMaxInactiveInterval(int secs) - negative value indicates session should never time out.
5.2.5. session may expire manually, when it is explicitly invalidated by a servlet by calling invalidate()
5.2.6. a server shutdown may or may not invalidate a session, depending on the capabilities of the server
5.2.7. when a session expires (or is invalidated), the HttpSession object and the data values it contains are removed from the system; if you need to retain information beyond a session lifespan, you should keep it in an external location (e.g. a database)

5.3. given that url-rewriting must be used for session management, identify the design requirement on session-related html pages

5.3.1. For a servlet to support session tracking via URL rewriting, it has to rewrite every local URL before sending it to the client.
5.3.2. public String HttpServletResponse.encodeURL(String url)
5.3.3. public String HttpServletResponse.encodeRedirectURL(String url)
5.3.4. both methods encode the given url to include the session id and returns the new url, or, if encoding is not needed or is not supported, it leaves the url unchanged. The rules for when and how to encode are server-specific.
5.3.5. note that when using session tracking based on url rewriting that multiple browser windows can belong to different sessions or the same session, depending on how the windows were created and whether the link creating the windows was url rewritten.

5.4. Note: Using Cookies:

5.4.1.1. To send a cookie to a client: {Cookie cookie = new Cookie("name", "value"); res.addCookie(cookie);}.
5.4.1.2. To retrieve cookies: {Cookie[] cookies = req.getCookies();}

Java SCJP 6 Exam Download
Java SCJP 6 Exam Details

Previous                                                   Contents                                                         Next 

Privacy Policy Legal Contact webmaster Web design by anandsoft