The following sections describe how to set up sessions and session persistence:

• Overview of HTTP Sessions

• Setting Up Session Management

• Configuring Session Persistence

• Using URL Rewriting

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:

• How many users you expect to hit the servlet

• How many concurrent users hit the servlet

• How long each session lasts

• How much data you expect to store for each user

• Heap size allocated to the WebLogic Server instance.

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:

• Set the TimeoutSecs attribute in thejsp-descriptor of the WebLogic-specific deployment descriptor, weblogic.xml. This value is set in seconds.

• Set the <session-timeout>(see session-config)element in the Web Application deployment descriptor, web.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:

• Memory (single-server, non-replicated)

• File system persistence

• JDBC persistence

• Cookie-based session persistence

• In-memory replication (across a cluster)

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:

CacheSize

Limits the number of cached sessions that can be active in memory at any one time. If you are expecting high volumes of simultaneous active sessions, you do not want these sessions to soak up the RAM of your server since this may cause performance problems swapping to and from virtual memory. When the cache is full, the least recently used sessions are stored in the persistent store and recalled automatically when required. If you do not use persistence, this property is ignored, and there is no soft limit to the number of sessions allowed in main memory. By default, the number of cached sessions is 1024. The minimum is 16, and maximum is Integer.MAX_VALUE. An empty session uses less than 100 bytes, but grows as data is added to it.

SwapIntervalSecs

The interval the server waits between purging the least recently used sessions from the cache to the persistent store, when the cacheEntries limit has been reached.

If unset, this property defaults to 10 seconds; minimum is 1 second, and maximum is 604800 (1 week).

InvalidationIntervalSecs

Sets the time, in seconds, that WebLogic Server waits between doing house-cleaning checks for timed-out and invalid sessions, and deleting the old sessions and freeing up memory. Set this parameter to a value less than the value set for the <session-timeout> element. Use this parameter to tune WebLogic Server for best performance on high traffic sites.

The minimum value is every second (1). The maximum value is once a week (604,800 seconds). If unset, the parameter defaults to 60 seconds.

To set <session-timeout>, see the session-config of the Web Application deployment descriptor web.xml.

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:

1. Set the PersistentStoreType property in the <session-descriptor> element in the deployment descriptor file weblogic.xml to file.
2. Set the directory where WebLogic Server stores the sessions. See PersistentStoreDir.

   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:

1. Set the PersistentStoreType property in the <session-descriptor> element of the WebLogic-specific deployment descriptor, weblogic.xml, to jdbc.
2. Set a JDBC connection pool to be used for persistence storage with the PersistentStorePool property of the WebLogic-specific deployment descriptor, weblogic.xml. Use the name of a connection pool that is defined in the WebLogic Server Administration Console.

   For more details on setting up a database connection pool, see Managing JDBC Connectivity.

3. Set an ACL for the connection that corresponds to the users that have permission. For more details on setting up a database connection, see Managing JDBC Connectivity.
4. Set up a database table named wl_servlet_sessions for JDBC-based persistence. The connection pool that connects to the database needs to have read/write access for this table. The following table shows the Column names and data types you should use when creating this table.

If you are using an Oracle DBMS, use the following SQL statement to create the wl_servlet_sessions table:

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) ); 

If you are using SqlServer2000, use the following SQL statement to create the wl_servlet_sessions table:

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) ); 

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:

• You can store only string attributes in the session. If you store any other type of object in the session, an IllegalArgument exception is thrown.

• You cannot flush the HTTP response (because the cookie must be written to the header data before the response is committed).

• If the content length of the response exceeds the buffer size, the response is automatically flushed and the session data cannot be updated in the cookie. (The buffer size is, by default, 8192 bytes. You can change the buffer size with the javax.servlet.ServletResponse.setBufferSize() method.

• You can only use basic (browser-based) authentication.

• Session data is sent to the browser in clear text.

• The user's browser must be configured to accept cookies.

• You cannot use commas (,) in a string when using cookie-based session persistence or an exception occurs.

To set up cookie-based session persistence:

1. In the <session-descriptor> element of weblogic.xml, set the PersistentStoreType parameter to cookie.
2. Optionally, set a name for the cookie using the PersistentStoreCookieName parameter. The default is WLCOOKIE.

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.

• Avoid writing a URL straight to the output stream, as shown here:

  out.println("<a href=\"/myshop/catalog.jsp\">catalog</a>");

  Instead, use the HttpServletResponse.encodeURL() method, for example:

  out.println("<a href=\""
       + response.encodeURL("myshop/catalog.jsp") 
       + "\">catalog</a>");

  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.

• In addition to URLs that are returned as a response to WebLogic Server, also encode URLs that send redirects. For example:

  if (session.isNew())
    response.sendRedirect (response.encodeRedirectUrl(welcomeURL));  

  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.

• Your servlet can determine whether a given session ID was received from a cookie by checking the Boolean returned from the HttpServletRequest.isRequestedSessionIdFromCookie() method. Your application may respond appropriately, or simply rely on URL rewriting by WebLogic Server.

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.

选自<<精通Hibernate：Java对象持久化技术详解>> 作者：孙卫琴 来源:www.javathinker.org
如果转载，请标明出处，谢谢

1.1 Hibernate API 变化
1.1.1 包名
1.1.2 org.hibernate.classic包
1.1.3 Hibernate所依赖的第三方软件包
1.1.4 异常模型
1.1.5 Session接口
1.1.6 createSQLQuery()
1.1.7 Lifecycle 和 Validatable 接口
1.1.8 Interceptor接口
1.1.9 UserType和CompositeUserType接口
1.1.10 FetchMode类
1.1.11 PersistentEnum类
1.1.12 对Blob 和Clob的支持
1.1.13 Hibernate中供扩展的API的变化
1.2 元数据的变化
1.2.1 检索策略
1.2.2 对象标识符的映射
1.2.3 集合映射
1.2.4 DTD
1.3 查询语句的变化
1.3.1 indices()和elements()函数

尽管Hibernate 3.0 与Hibernate2.1的源代码是不兼容的，但是当Hibernate开发小组在设计Hibernate3.0时，为简化升级Hibernate版本作了周到的考虑。对于现有的基于Hibernate2.1的Java项目，可以很方便的把它升级到Hibernate3.0。

本文描述了Hibernate3.0版本的新变化，Hibernate3.0版本的变化包括三个方面：
（1）API的变化，它将影响到Java程序代码。
（2）元数据，它将影响到对象-关系映射文件。
（3）HQL查询语句。

值得注意的是， Hibernate3.0并不会完全取代Hibernate2.1。在同一个应用程序中，允许Hibernate3.0和Hibernate2.1并存。

1.1 Hibernate API 变化

1.1.1 包名

Hibernate3.0的包的根路径为: “org.hibernate” ，而在Hibernate2.1中为“net.sf.hibernate”。这一命名变化使得Hibernate2.1和Hibernate3.0能够同时在同一个应用程序中运行。

如果希望把已有的应用升级到Hibernate3.0，那么升级的第一步是把Java源程序中的所有“net.sf.hibernate”替换为“org.hibernate”。

Hibernate2.1中的“net.sf.hibernate.expression”包被改名为“org.hibernate.criterion”。假如应用程序使用了Criteria API，那么在升级的过程中，必须把Java源程序中的所有“net.sf.hibernate.expression”替换为“org.hibernate.criterion”。

如果应用使用了除Hibernate以外的其他外部软件，而这个外部软件又引用了Hibernate的接口，那么在升级时必须十分小心。例如EHCache拥有自己的CacheProvider： net.sf.ehcache.hibernate.Provider，在这个类中引用了Hibernate2.1中的接口，在升级应用时，可以采用以下办法之一来升级EHCache:

（1）手工修改net.sf.ehcache.hibernate.Provider类，使它引用Hibernate3.0中的接口。
（2）等到EHCache软件本身升级为使用Hibernate3.0后，使用新的EHCache软件。
（3）使用Hibernate3.0中内置的CacheProvider：org.hibernate.cache.EhCacheProvider。

1.1.2 org.hibernate.classic包

Hibernate3.0把一些被废弃的接口都转移到org.hibernate.classic中。

1.1.3 Hibernate所依赖的第三方软件包

在Hibernate3.0的软件包的lib目录下的README.txt文件中，描述了Hibernate3.0所依赖的第三方软件包的变化。

1.1.4 异常模型

在Hibernate3.0中，HibernateException异常以及它的所有子类都继承了java.lang.RuntimeException。因此在编译时，编译器不会再检查HibernateException。

1.1.5 Session接口

在Hibernate3.0中，原来Hibernate2.1的Session接口中的有些基本方法也被废弃，但为了简化升级，这些方法依然是可用的，可以通过org.hibernate.classic.Session子接口来访问它们，例如：

org.hibernate.classic.Session session=sessionFactory.openSession();
session.delete("delete from Customer ");

在Hibernate3.0中，org.hibernate.classic.Session接口继承了org.hibernate.Session接口，在org.hibernate.classic.Session接口中包含了一系列被废弃的方法，如find()、interate()等。SessionFactory接口的openSession()方法返回org.hibernate.classic.Session类型的实例。如果希望在程序中完全使用Hibernate3.0，可以采用以下方式创建Session实例：

org.hibernate.Session session=sessionFactory.openSession();

如果是对已有的程序进行简单的升级，并且希望仍然调用Hibernate2.1中Session的一些接口，可以采用以下方式创建Session实例：

org.hibernate.classic.Session session=sessionFactory.openSession();

在Hibernate3.0中，Session接口中被废弃的方法包括：
* 执行查询的方法：find()、iterate()、filter()和delete(String hqlSelectQuery)
* saveOrUpdateCopy()

Hibernate3.0一律采用createQuery()方法来执行所有的查询语句，采用DELETE 查询语句来执行批量删除，采用merge()方法来替代 saveOrUpdateCopy()方法。

提示：在Hibernate2.1中，Session的delete()方法有几种重载形式，其中参数为HQL查询语句的delete()方法在Hibernate3.0中被废弃，而参数为Ojbect类型的的delete()方法依然被支持。delete(Object o)方法用于删除参数指定的对象，该方法支持级联删除。

Hibernate2.1没有对批量更新和批量删除提供很好的支持，参见<<精通Hibernate>>一书的第13章的13.1.1节（批量更新和批量删除），而Hibernate3.0对批量更新和批量删除提供了支持，能够直接执行批量更新或批量删除语句，无需把被更新或删除的对象先加载到内存中。以下是通过Hibernate3.0执行批量更新的程序代码：

Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();

String hqlUpdate = "update Customer set name = :newName where name = :oldName";
int updatedEntities = s.createQuery( hqlUpdate )
.setString( "newName", newName )
.setString( "oldName", oldName )
.executeUpdate();
tx.commit();
session.close();

以下是通过Hibernate3.0执行批量删除的程序代码：

Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();

String hqlDelete = "delete Customer where name = :oldName";
int deletedEntities = s.createQuery( hqlDelete )
.setString( "oldName", oldName )
.executeUpdate();
tx.commit();
session.close();

1.1.6 createSQLQuery()

在Hibernate3.0中，Session接口的createSQLQuery()方法被废弃，被移到org.hibernate.classic.Session接口中。Hibernate3.0采用新的SQLQuery接口来完成相同的功能。

1.1.7 Lifecycle 和 Validatable 接口

Lifecycle和Validatable 接口被废弃，并且被移到org.hibernate.classic包中。

1.1.8 Interceptor接口

在Interceptor 接口中加入了两个新的方法。 用户创建的Interceptor实现类在升级的过程中，需要为这两个新方法提供方法体为空的实现。此外，instantiate()方法的参数作了修改，isUnsaved()方法被改名为isTransient()。

1.1.9 UserType和CompositeUserType接口

在UserType和CompositeUserType接口中都加入了一些新的方法，这两个接口被移到org.hibernate.usertype包中，用户定义的UserType和CompositeUserType实现类必须实现这些新方法。

Hibernate3.0提供了ParameterizedType接口，用于更好的重用用户自定义的类型。

1.1.10 FetchMode类

FetchMode.LAZY 和 FetchMode.EAGER被废弃。取而代之的分别为FetchMode.SELECT 和FetchMode.JOIN。

1.1.11 PersistentEnum类

PersistentEnum被废弃并删除。已经存在的应用应该采用UserType来处理枚举类型。

1.1.12 对Blob 和Clob的支持

Hibernate对Blob和Clob实例进行了包装，使得那些拥有Blob或Clob类型的属性的类的实例可以被游离、序列化或反序列化，以及传递到merge()方法中。

1.1.13 Hibernate中供扩展的API的变化

org.hibernate.criterion、 org.hibernate.mapping、 org.hibernate.persister和org.hibernate.collection 包的结构和实现发生了重大的变化。多数基于Hibernate
2.1 的应用不依赖于这些包，因此不会被影响。如果你的应用扩展了这些包中的类，那么必须非常小心的对受影响的程序代码进行升级。

1.2 元数据的变化

1.2.1 检索策略

在Hibernate2.1中，lazy属性的默认值为“false”，而在Hibernate3.0中，lazy属性的默认值为“true”。在升级映射文件时，如果原来的映射文件中的有关元素，如<set>、<class>等没有显式设置lazy属性，那么必须把它们都显式的设置为lazy=“true”。如果觉得这种升级方式很麻烦，可以采取另一简单的升级方式：在<hibernate-mapping>元素中设置: default-lazy=“false”。

1.2.2 对象标识符的映射

unsaved-value属性是可选的，在多数情况下，Hibernate3.0将把unsaved-value="0" 作为默认值。

在Hibernate3.0中，当使用自然主键和游离对象时，不再强迫实现Interceptor.isUnsaved()方法。 如果没有设置这个方法，当Hibernate3.0无法区分对象的状态时，会查询数据库，来判断这个对象到底是临时对象，还是游离对象。不过，显式的使用Interceptor.isUnsaved()方法会获得更好的性能，因为这可以减少Hibernate直接访问数据库的次数。

1.2.3 集合映射

<index>元素在某些情况下被<list-index>和<map-key>元素替代。此外，Hibernate3.0用<map-key-many-to-many> 元素来替代原来的<key-many-to-many>.元素，用<composite-map-key>元素来替代原来的<composite-index>元素。

1.2.4 DTD

对象-关系映射文件中的DTD文档，由原来的：
http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd
改为：
http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd

1.3 查询语句的变化

Hibernate3.0 采用新的基于ANTLR的HQL/SQL查询翻译器，不过，Hibernate2.1的查询翻译器也依然存在。在Hibernate的配置文件中，hibernate.query.factory_class属性用来选择查询翻译器。例如：
（1）选择Hibernate3.0的查询翻译器：
hibernate.query.factory_class= org.hibernate.hql.ast.ASTQueryTranslatorFactory
（2）选择Hibernate2.1的查询翻译器
hibernate.query.factory_class= org.hibernate.hql.classic.ClassicQueryTranslatorFactory

提示：ANTLR是用纯Java语言编写出来的一个编译工具，它可生成Java语言或者是C++的词法和语法分析器，并可产生语法分析树并对该树进行遍历。ANTLR由于是纯Java的，因此可以安装在任意平台上，但是需要JDK的支持。

Hibernate开发小组尽力保证Hibernate3.0的查询翻译器能够支持Hibernate2.1的所有查询语句。不过，对于许多已经存在的应用，在升级过程中，也不妨仍然使用Hibernate2.1的查询翻译器。
值得注意的是， Hibernate3.0的查询翻译器存在一个Bug：不支持某些theta-style连结查询方言：如Oracle8i的OracleDialect方言、Sybase11Dialect。解决这一问题的办法有两种：（1）改为使用支持ANSI-style连结查询的方言，如 Oracle9Dialect,（2）如果升级的时候遇到这一问题，那么还是改为使用Hibernate2.1的查询翻译器。

1.3.1 indices()和elements()函数

在HQL的select子句中废弃了indices()和elements()函数，因为这两个函数的语法很让用户费解，可以用显式的连接查询语句来替代 select elements(...) 。而在HQL的where子句中，仍然可以使用elements()函数。