Using Sessions and Session Persistence in Web Applications
来源:互联网 发布:淘宝链接转微信链接 编辑:程序博客网 时间:2024/05/18 03:02
The following sections describe how to set up sessions and session persistence: Overview of HTTP Sessions Session tracking enables you to track a user's progress over multiple servlets or HTML pages, which, by nature, are stateless. A session is defined as a series of related browser requests that come from the same client during a certain time period. Session tracking ties together a series of browser requests—think of these requests as pages—that may have some meaning as a whole, such as a shopping cart application. Setting Up Session Management WebLogic Server is set up to handle session tracking by default. You need not set any of these properties to use session tracking. However, configuring how WebLogic Server manages sessions is a key part of tuning your application for best performance. Tuning depends upon factors such as: HTTP Session Properties You configure WebLogic Server session tracking with properties in the WebLogic-specific deployment descriptor, weblogic.xml. For instructions on editing the WebLogic-specific deployment descriptor, see Step 4: Define session parameters. For a complete list of session attributes, see jsp-descriptor. WebLogic Server 7.0 introduced a change to the SessionID format that caused some load balancers to lose the ability to retain session stickiness. A new server startup flag, -Dweblogic.servlet.useExtendedSessionFormat=true , retains the information that the load-balancing application needs for session stickiness. The extended session ID format will be part of the URL if URL rewriting is activated, and the startup flag is set to true. Session Timeout You can specify an interval of time after which HTTP sessions expire. When a session expires, all data stored in the session is discarded. You can set the interval in either web.xml or weblogic.xml: Configuring Session Cookies WebLogic Server uses cookies for session management when supported by the client browser. The cookies that WebLogic Server uses to track sessions are set as transient by default and do not outlive the session. When a user quits the browser, the cookies are lost and the session lifetime is regarded as over. This behavior is in the spirit of session usage and it is recommended that you use sessions in this way. You can configure session-tracking attributes of cookies in the WebLogic-specific deployment descriptor, weblogic.xml. A complete list of session and cookie-related attributes is available jsp-descriptor. For instructions on editing the WebLogic-specific deployment descriptor, see Step 4: Define session parameters. Using Cookies That Outlive a Session For longer-lived client-side user data, your application should create and set its own cookies on the browser via the HTTP servlet API, and should not attempt to use the cookies associated with the HTTP session. Your application might use cookies to auto-login a user from a particular machine, in which case you would set a new cookie to last for a long time. Remember that the cookie can only be sent from that client machine. Your application should store data on the server if it must be accessed by the user from multiple locations. You cannot directly connect the age of a browser cookie with the length of a session. If a cookie expires before its associated session, that session becomes orphaned. If a session expires before its associated cookie, the servlet is not be able to find a session. At that point, a new session is assigned when the request.getSession(true) method is called. You should only make transient use of sessions. You can set the maximum life of a cookie with the CookieMaxAgeSecs parameter in the session descriptor of the weblogic.xml deployment descriptor. For more information, see Step 4: Define session parameters Logging Out and Ending a Session User authentication information is stored both in the user's session data and in the context of a server or virtual host that is targeted by a Web Application. The session.invalidate() method, which is often used to log out a user, only invalidates the current session for a user—the user's authentication information still remains valid and is stored in the context of the server or virtual host. If the server or virtual host is hosting only one Web Application, the session.invalidate() method, in effect, logs out the user. There are several Java methods and strategies you can use when using authentication with multiple Web Applications. For more information, see Implementing Single Sign-On in the Programming WebLogic HTTP Servlets,. Configuring Session Persistence Use Session Persistence to permanently stored data from an HTTP session object in order to enable failover and load balancing across a cluster of WebLogic Servers. When your applications stores data in an HTTP session object, the data must be serializable. There are five different implementations of session persistence: The first four are discussed here; in-memory replication is discussed in "HTTP Session State Replication," in Using WebLogic Server Clusters. File, JDBC, Cookie-based, and memory (single-server, non-populated) session persistence have some common properties. Each persistence method has its own set of attributes, as discussed in the following sections. Common Properties of Session Attributes This section describes attributes common to file system, memory (single-server, non-replicated), JDBC, and cookie-based persistence. You can configure the number of sessions that are held in memory by setting the following properties in the <session-descriptor> element of the WebLogic-specific deployment descriptor, weblogic.xml. These properties are only applicable if you are using session persistence: Using Memory-based, Single-server, Non-replicated Persistent Storage To use memory-based, single-server, non-replicated persistent storage, set the PersistentStoreType property in the <session-descriptor> element of the WebLogic-specific deployment descriptor, weblogic.xml to memory.When you use memory-based storage, all session information is stored in memory and is lost when you stop and restart WebLogic Server. Note:If you do not allocate sufficient heap size when running WebLogic Server, your server may run out of memory under heavy load. Using File-based Persistent Storage To configure file-based persistent storage for sessions: If you do not explicitly set a value for this attribute, a temporary directory is created for you by WebLogic Server. If you are using file-based persistence in a cluster, you must explicitly set this attribute to a shared directory that is accessible to all the servers in a cluster. You must create this directory yourself. Using a Database for Persistent Storage (JDBC persistence) JDBC persistence stores session data in a database table using a schema provided for this purpose. You can use any database for which you have a JDBC driver. You configure database access by using connection pools. To configure JDBC-based persistent storage for sessions: For more details on setting up a database connection pool, see Managing JDBC Connectivity. Column name Type wl_id Variable-width alphanumeric column, up to 100 characters; for example, Oracle VARCHAR2(100). wl_id + wl_context_path. wl_context_path Variable-width alphanumeric column, up to 100 characters; for example, Oracle VARCHAR2(100). This column is used as part of the primary key. (See the wl_id column description.) wl_is_new Single char column; for example, Oracle CHAR(1) wl_create_time Numeric column, 20 digits; for example, Oracle NUMBER(20) wl_is_valid Single char column; for example, Oracle CHAR(1) wl_session_values Large binary column; for example, Oracle LONG RAW wl_access_time Numeric column, 20 digits; for example, NUMBER(20) wl_max_inactive_interval Integer column; for example, Oracle Integer. Number of seconds between client requests before the session is invalidated. A negative time value indicates that the session should never timeout. If you are using an Oracle DBMS, use the following SQL statement to create the wl_servlet_sessions table: If you are using SqlServer2000, use the following SQL statement to create the wl_servlet_sessions table: Modify one of the preceeding SQL statements for use with your DBMS. Note:You can configure a maximum duration that JDBC session persistence should wait for a JDBC connection from the connection pool before failing to load the session data with the JDBCConnectionTimeoutSecs attribute. For more information, see JDBCConnectionTimeoutSecs. Using Cookie-Based Session Persistence Cookie-based session persistence provides a stateless solution for session persistence by storing all session data in a cookie that is stored in the user's browser. Cookie-based session persistence is most useful when you do not need to store large amounts of data in the session. Cookie-based session persistence can make managing your WebLogic Server installation easier because clustering failover logic is not required. Because the session is stored in the browser, not on the server, you can start and stop WebLogic Servers without losing sessions. There are some limitations to cookie-based session persistence: To set up cookie-based session persistence: Using URL Rewriting In some situations, a browser or wireless device may not accept cookies, which makes session tracking using cookies impossible. URL rewriting is a solution to this situation that can be substituted automatically when WebLogic Server detects that the browser does not accept cookies. URL rewriting involves encoding the session ID into the hyper-links on the Web pages that your servlet sends back to the browser. When the user subsequently clicks these links, WebLogic Server extracts the ID from the URL address and finds the appropriate HttpSession when your servlet calls the getSession() method. Enable URL rewriting in WebLogic Server by setting the URLRewritingEnabled attribute in the WebLogic-specific deployment descriptor, weblogic.xml, under the <session-descriptor> element. The default value for this attribute is true. See URLRewritingEnabled. Coding Guidelines for URL Rewriting There are some general guidelines for how your code should handle URLs in order to support URL rewriting. Instead, use the HttpServletResponse.encodeURL() method, for example: Calling the encodeURL() method determines if the URL needs to be rewritten, and if so, it rewrites it by including the session ID in the URL. The session ID is appended to the URL and begins with a semicolon. WebLogic Server uses URL rewriting when a session is new, even if the browser does accept cookies, because the server cannot tell whether a browser accepts cookies in the first visit of a session. URL Rewriting and Wireless Access Protocol (WAP) If you are writing a WAP application, you must use URL rewriting because the WAP protocol does not support cookies. In addition, some WAP devices have a 128-character limit on the length of a URL (including parameters), which limits the amount of data that can be transmitted using URL rewriting. To allow more space for parameters, you can limit the size of the session ID that is randomly generated by WebLogic Server. See IDLength.
The primary key must be set as follows:create table wl_servlet_sessions
( wl_id VARCHAR2(100) NOT NULL,
wl_context_path VARCHAR2(100) NOT NULL,
wl_is_new CHAR(1),
wl_create_time NUMBER(20),
wl_is_valid CHAR(1),
wl_session_values LONG RAW,
wl_access_time NUMBER(20),
wl_max_inactive_interval INTEGER,
PRIMARY KEY (wl_id, wl_context_path) ); create table wl_servlet_sessions
( wl_id VARCHAR2(100) NOT NULL,
wl_context_path VARCHAR2(100) NOT NULL,
wl_is_new VARCHAR(1),
wl_create_time DeCIMAL,
wl_is_valid VARCHAR(1),
wl_session_values IMAGE,
wl_access_time DECIMAL,
wl_max_inactive_interval INTEGER,
PRIMARY KEY (wl_id, wl_context_path) ); out.println("<a href=/"/myshop/catalog.jsp/">catalog</a>");
out.println("<a href=/""
+ response.encodeURL("myshop/catalog.jsp")
+ "/">catalog</a>");if (session.isNew())
response.sendRedirect (response.encodeRedirectUrl(welcomeURL));
- URL重写Using Sessions and Session Persistence in Web Applications
- Using Sessions and Session Persistence in Web Applications
- Mixing JSTL and JSF in Web Applications
- Using Windows XP Visual Styles and PrintWindow in Windows Applications
- Using NHibernate and Log4Net in ASP.NET 2.0 applications
- Using JavaScript in Page Flow and Portal Applications
- Using Boost Libraries in Windows Store and Phone Applications
- Developing SharePoint WebParts using User Controls and Web Applications
- Developing SharePoint WebParts using User Controls and Web Applications
- Using Session State in a Web Service
- Introduction to using Java Persistence API in a web application in Java EE environment
- Using MultipartEntity in Android applications
- Using RequireJS in AngularJS Applications
- Using RequireJS in AngularJS Applications
- Creating Web Applications in JavaScript with Express.js and ejs
- How-To : Using EJB 3.0 and Java Persistence API with Spring in OC4J
- Using files from web applications
- Data Transfer between Business and Data Access Components in Enterprise Applications using .Net
- oracle 创建表空间
- 第二步 对象
- 首届 ANA(Android Network Awards)提名公布
- 如何把DataGridView中的数据库打印出来
- 单例模式
- Using Sessions and Session Persistence in Web Applications
- 正则表达式
- 根据网上搜到的代码,自己整理的jpeg解码程序
- 深入理解C语言指针的奥秘
- 正则表达式速成
- 结合Flex Builder和Flash CS4制作一个中国地图的应用
- 序列号生成器
- Oracle用户权限
- 润乾报表数据集从Text文件中读取方法