Presentation is loading. Please wait.

Presentation is loading. Please wait.

® IBM Software Group © 2007 IBM Corporation Best Practices for Session Management 4.1.0.3.

Similar presentations


Presentation on theme: "® IBM Software Group © 2007 IBM Corporation Best Practices for Session Management 4.1.0.3."— Presentation transcript:

1 ® IBM Software Group © 2007 IBM Corporation Best Practices for Session Management 4.1.0.3

2 2 After completing this unit, you should be able to:  Examine options for session management  Identify advantages and disadvantages of each option  Examine special concerns with cluster configurations  Identify techniques for using sessions efficiently After completing this unit, you should be able to:  Examine options for session management  Identify advantages and disadvantages of each option  Examine special concerns with cluster configurations  Identify techniques for using sessions efficiently Unit objectives

3 3 Session state can be stored on either the client or the server You examine several session management strategies and figure out where each applies  Cookies  Hidden Fields  URL Rewriting  Store state in a database  WebSphere Application Server Distributed Sessions  WebSphere Application Server Session Affinity Client Side Server Side Session Strategies - Review

4 4 Cookies for Session State (1 of 2)  Advantages  Unique to a client machine  Easy to use  Automatically passed in the header  Does not require explicitly coding hidden fields or URL query strings in the HTML and JSP pages  Makes the application much simpler to develop, test, and maintain  Range of lifetimes  Disadvantages  Can be turned off  May need to use URL rewriting  Not secure  Limit of 4096 bytes per cookie

5 5 Cookies for Session State (2 of 2)  Conclusion:  Use cookies only for small data sets that are not secure  A backup plan may be needed for situations where cookies are disabled

6 6 Hidden Fields  HTML includes a way to embed non-displayable information in an INPUT tag.  Allows information from previous interactions to be carried through to a new form:  Hidden fields are read back like any other field.  Use req.getParameter(String)  where req is an instance of HttpServletRequest  Hidden fields are stored on the client, in the HTML page itself.

7 7 Hidden Fields for Session State (1 of 2)  Advantages  Unique to each client  Can handle larger data than cookies  Cannot be turned off  Relatively simple  Server independence while maintaining session data  Disadvantages  Security can be compromised (can be spoofed)  Not secure under HTTP  Data is always transferred both ways, increasing network traffic and potentially impacting performance  Not supported by a framework like HttpSession  Only works with dynamically generated forms  Text only

8 8 Hidden Fields for Session State (2 of 2)  Conclusion:  Useful for medium-size data sets  Useful in a cluster configuration

9 9 In most cases you want to store session information in a datastore Allows the use of session clustering WAS Server Session Storage Options

10 10 WebSphere Distributed Sessions  WebSphere Application Server supports HttpSession in a clustered server environment with failover  Session information can be externally stored in:  Database persistent sessions  Memory-to-memory persistent sessions  Session attributes should be serializable  Session data is cached at the server level

11 11 WebSphere Application Server Session Affinity  Servlet API 2.4 requires HttpSession objects to be:  Accessible only to the Web application that created the session  Handled by a single JVM per application at any one time  Session affinity provides this capability in a cluster environment  Implemented via WebSphere Web server plug-in  Operation:  First request of a session selects server on a round-robin basis  Subsequent requests for that session go to the assigned server

12 12 Using HttpSession Objects Efficiently  Minimize number and size of attribute objects  Provide a logout function to invalidate session  session.invalidate()  Remove attributes from the session when they are no longer required  session.removeAttribute(String name)  Set JSP page directive session attribute to false when appropriate   Indicates page does not participate in user session  Implicit session variable is not available  Use a reasonable session timeout value  Balance user convenience versus resource consumption  Can be set in Web Deployment Descriptor

13 13 WebSphere Sessions  Each session access is a transaction in the database  Begins at getSession, ends at the end of the service method  Can choose to end prematurely with sync  This writes the data in the session object to the database  Improves performance; session persists only when necessary IBMSession session = (IBMSession)request.getSession(false); //... customer = (Customer) session.getAttribute(CommandConstants.CUSTOMER); //... // code that updates the customer goes here //... session.sync(); //...

14 14 WebSphere Administration Issues  Use cached session data  When the session data is already in memory, the improvements are as great as 50%  Configure maximum number of sessions  Helps manage the use of server resources  Use a dedicated database for the session database  Avoids contention for JDBC connections  Improves performance

15 15 Checkpoint 1.Name some of the advantages and disadvantages of using cookies, hidden fields, and HttpSession for session management 2.When would you need to store session data to a database?

16 16 Checkpoint solutions 1.Cookies: pro - easy to use, stored on each client machine; con - can be turned off, unsecure, limited in size. Hidden fields: pro - stored on client, cannot be turned off, easy to retrieve, can be larger than cookies; con - unsecure, transmitted both ways, must be generated dynamically. HttpSession; pro - stored on server, secure, supported by Servlet API; con - can be a problem when sharing across servers, maintaining session ID can be problematic (cookies, URL rewriting), can get quite large. 2.If you expect that a session started on one server may be switched to another server, and you are using session data to maintain state, you want to make that data available to any server by storing it in a database.

17 17 Having completed this unit, you should be able to:  Examine options for session management  Identify advantages and disadvantages of each option  Examine special concerns with cluster configurations  Identify techniques for using sessions efficiently Having completed this unit, you should be able to:  Examine options for session management  Identify advantages and disadvantages of each option  Examine special concerns with cluster configurations  Identify techniques for using sessions efficiently Unit summary


Download ppt "® IBM Software Group © 2007 IBM Corporation Best Practices for Session Management 4.1.0.3."

Similar presentations


Ads by Google