51 lines
4.3 KiB
HTML
51 lines
4.3 KiB
HTML
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||
|
|
<html>
|
||
|
|
<head>
|
||
|
|
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
|
||
|
|
<LINK rel="stylesheet" type="text/css" href="../../../rzahg/ic.css">
|
||
|
|
|
||
|
|
<title>Best practices for session programming</title>
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<BODY>
|
||
|
|
<!-- Java sync-link -->
|
||
|
|
<SCRIPT LANGUAGE="Javascript" SRC="../../../rzahg/synch.js" TYPE="text/javascript"></SCRIPT>
|
||
|
|
|
||
|
|
<h4><a name="sespract"></a>Best practices for session programming</h4>
|
||
|
|
|
||
|
|
<!--<p>When developing new objects to be stored in the HTTP session, make sure to implement the Serializable interface. Also ensure the java objects contained within your class are Serializable. This enables the object to properly persist session information to the database. An example of this is:</p>
|
||
|
|
|
||
|
|
<pre> public class MyObject implements java.io.Serializable {
|
||
|
|
...
|
||
|
|
}</pre>
|
||
|
|
|
||
|
|
<p>Without this extension, the object is not correctly persisted and throws an error.</p>-->
|
||
|
|
|
||
|
|
<p>Before you develop new objects to be stored in the HTTP session, make sure to consider enabling security integration. HTTP sessions are identified by session IDs, which are pseudo-random numbers that are generated at runtime. Session hijacking is a known attack on HTTP sessions and can be prevented if all requests going over the network are over a secure connection (HTTPS). Not every configuration in a customer environment enforces the security constraint because of potential SSL performance impacts, and HTTP sessions can become vulnerable to hijacking. WebSphere Application Server - Express can integrate HTTP sessions and application server security. Enable security in WebSphere Application Server - Express to protect sessions so that only session creators have access to those sessions.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<p>When adding Java objects to a session, make sure they are in the correct class path. If Java objects are added to a session, be sure to place the class files for those objects in the application server class path or in the Web module path. Because the HttpSession object is shared among servlets that the user might access, consider adopting a site-wide naming convention to avoid conflicts. <!--For more information, see <a href="sesdist.htm">Distributed session support</a>.--></p>
|
||
|
|
|
||
|
|
<p><strong>Note:</strong> Do not store large Object graphs in HttpSession.</p>
|
||
|
|
|
||
|
|
<p>In most applications, each servlet requires only a fraction of the total session data. However, by storing the data in HttpSession as one large object, an application forces WebSphere Application Server - Express to process all of it each time.</p>
|
||
|
|
|
||
|
|
<p>Release HttpSession objects when you are finished. HttpSession objects live inside the Web container until one of the following occurs:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><p>The application explicitly and programmatically releases it using javax.servlet.http.HttpSession.invalidate(). Quite often, programmatic invalidation is part of an application logout function.</p></li>
|
||
|
|
<li><p>The application server destroys the allocated HttpSession object when it expires (default is 1800 seconds or 30 minutes).</p></li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p><strong>Note:</strong> Do not try to save and reuse the HttpSession object outside of each servlet or JSP.</p>
|
||
|
|
|
||
|
|
<p>The HttpSession object is a function of the HttpServletRequest: you can get it only through the getSession() method. A copy of the HttpSession object is valid only for the life of the service() method of the servlet or JSP. You cannot cache the HttpSession object and refer to it outside the scope of a servlet or JSP.</p>
|
||
|
|
|
||
|
|
<!--<p>Distributed sessions require an affinity mechanism so that all requests for a particular session are directed to the same Java virtual machine in the cell. This conforms to the Servlet 2.3 Specification in that multiple requests for a session cannot coexist in multiple virtual machines. One such solution provided by WebSphere Application Server - Express is serialized session access, which is available as part of the WebSphere plug-ins for various Web servers.</p>
|
||
|
|
|
||
|
|
<p>If one of the servers in the cell fails, it is possible for the request to be rerouted to another server. The new server can access session data from the common SESSIONS table. This is transparent to the servlet, browser, and user. This helps to achieve a greater use of the in-memory cache.</p>-->
|
||
|
|
|
||
|
|
</body>
|
||
|
|
</html>
|
||
|
|
|