jzzjzzjzz亚洲成熟少妇,精品久久久久久最新网址,日韩大胆人体

DAO

wadise — Mon, 05 Jun 2006 15:10:00 GMT

许多Java开发员已经知道DAO模式。这个模式有许多不同的实玎ͼ��管如此�Q�在�q�篇文章中将阐述DAO实现的设惻I��
1.�pȝ��中所有数据库讉K��都通过DAO来包�?br />2.每个DAO实例代表一个原生的领域对象或实体。如果一个领域对象有一个独立的生命周期�Q�那么它应该有自��q��DAO�?br />3.DAO代表在领域对象上的CURD操作�?br />4.DAO允许��Z��Criteria的查询不同于用主键查询。我比较們֐�构造一个finder�Ҏ��。该finder�Ҏ��的返回值是一个领域对象组的Collection集合
5.DAO不代表处理事务，Sessions或连接。这些在DAO外处理将更加灉|��?br />
例子�Q?br />GenericDao是CRUD操作的DAO基类�?br />

public interface GenericDao <T, PK extends Serializable> {

    /** Persist the newInstance object into database */
    PK create(T newInstance);

    /** Retrieve an object that was previously persisted to the database using
     *   the indicated id as primary key
     */
    T read(PK id);

    /** Save changes made to a persistent object.  */
    void update(T transientObject);

    /** Remove an object from persistent storage in the database */
    void delete(T persistentObject);
}

下面是它的实现类�Q?br />

public class GenericDaoHibernateImpl <T, PK extends Serializable>
    implements GenericDao<T, PK>, FinderExecutor {
    private Class<T> type;

    public GenericDaoHibernateImpl(Class<T> type) {
        this.type = type;
    }

    public PK create(T o) {
        return (PK) getSession().save(o);
    }

    public T read(PK id) {
        return (T) getSession().get(type, id);
    }

    public void update(T o) {
        getSession().update(o);
    }

    public void delete(T o) {
        getSession().delete(o);
    }
}

扩展GenericDAO

public interface PersonDao extends GenericDao<Person, Long> {
List<Person> findByName(String name);
}

wadise 2006-06-05 23:10 发表评论

wadise — Mon, 05 Jun 2006 14:29:00 GMT

通常我们在初始化一个Map的时候，都要�q�样子：

Map test = new HashMap();
test.put("1", "11");
test.put("2", "22");

�q�样��显得有点太�J�烦�Q�不像动态语�a�那么灉|��。。但是我们可以这样写�Q?br />

Map test = new HashMap() {
  {
    put("1", "11");
    put("2", "22");
   }
};

Collection同理!

wadise 2006-06-05 22:29 发表评论

wadise — Tue, 09 May 2006 12:27:00 GMT

原文�Q�http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770

Using Sessions and Session Persistence in Web Applications

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 (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 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 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

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

, 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 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:

Set the PersistentStoreType property in the element in the deployment descriptor file weblogic.xml to file.
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:

Set the PersistentStoreType property in the element of the WebLogic-specific deployment descriptor, weblogic.xml, to jdbc.
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.
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.
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.

Column name	Type
wl_id	Variable-width alphanumeric column, up to 100 characters; for example, Oracle VARCHAR2(100). The primary key must be set as follows: 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_idcolumn 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:

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:

In the element of weblogic.xml, set the PersistentStoreType parameter to cookie.
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 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("catalog");
```
Instead, use the HttpServletResponse.encodeURL() method, for example:
```
out.println("     + response.encodeURL("myshop/catalog.jsp") 
     + "\">catalog");
```
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.

wadise 2006-05-09 20:27 发表评论

HttpSession一�Q��{载）

wadise — Tue, 09 May 2006 12:26:00 GMT

原文�Q�http://www.javaresearch.org/article/showarticle.jsp?column=106&thread=45120

摘要�Q�虽然session机制在web应用�E�序中被采用已经很长旉��了，但是仍然有很多�h不清楚session机制的本质，以至不能正确的应用这一技术�? 本文��详�l�讨论session的工作机制�ƈ且对在Java web application中应用session机制时常见的问题作出解答�?br />
目录�Q?br />一、术语session
二、HTTP协议与状态保�?br />三、理解cookie机制
四、理解session机制
五、理解javax.servlet.http.HttpSession
六、HttpSession常见问题
七、跨应用�E�序的session�׃�n
八、�ȝ��
参考文�?br />
一、术语session
在我的经验里�Q�session�q�个词被滥用的程度大概仅�ơ于transaction�Q�更加有��的是transaction与session在某些语境下的含义是相同的�?br />
session�Q? 中文�l�常��译��Z��话，其本来的含义是指有始有终的一�p�d��动作/消息�Q�比如打电话时从拿�v电话拨号到挂断电话这中间的一�p�d��q�程可以�U�C��Z��? session。有时候我们可以看到这��L��话“在一个浏览器会话期间�Q?..”，�q�里的会话一词用的就是其本义�Q�是指从一个浏览器�H�口打开到关闭这个期闾b�①。最混�ؕ的是“用��P��客户端）在一�ơ会话期间”这样一句话�Q�它可能指用��L��一�p�d��动作�Q�一般情况下是同某个具体目的相关的一�p�d��动作�Q�比如从��d��? 选购商品到结账登��样一个网上购物的�q�程�Q�有时候也被称��Z��个transaction�Q�，然而有时候也可能仅仅是指一�ơ连接，也有可能是指含义①，其中的差别只能靠上下文来推断②�?br />
然而当session一词与�|�络协议相关联时�Q�它又往往隐含了“面向连接”和/或“保持状态”这样两个含义， “面向连接”指的是在通信双方在通信之前要先建立一个通信的渠道，比如打电话，直到�Ҏ��接了电话通信才能开始，与此相对的是写信�Q�在你把信发出去�? 时候你�q�不能确认对方的地址是否正确�Q�通信渠道不一定能建立�Q�但对发信�h来说�Q�通信已经开始了。“保持状态”则是指通信的一方能够把一�p�d��的消息关联�v 来，使得消息之间可以互相依赖�Q�比如一个服务员能够认出再次光��的老顾客�ƈ且记得上�ơ这个顾客还�Ơ店里一块钱。这一�cȝ��例子有“一�? TCP session”或者 “一个POP3 session”③�?br />
而到了web服务器蓬勃发展的时代�Q�session在web开发语境下的语义又有了新的扩展�Q�它的含义是指一�cȝ��来在客户端与服务器之间保持状态的解决�Ҏ��④。有时候session也用来指�q�种解决�Ҏ��的存储结构，�? “把xxx保存在session 里”⑤。由于各�U�用于web开发的语言在一定程度上都提供了对这�U�解��x��案的支持�Q�所以在某种特定语言的语境下�Q? session也被用来指代该语�a�的解��x��案，比如�l�常把Java里提供的javax.servlet.http.HttpSession��U�Cؓ session⑥�?br />
鉴于�q�种混�ؕ已不可改变，本文中session一词的�q�用也会�Ҏ��上下文有不同的含义，请大家注意分辨�?br />在本文中�Q��用中文“浏览器会话期间”来表达含义①，使用“session机制”来表达含义④，使用“session”表辑֐�义⑤�Q��用具体的“HttpSession”来表达含义�?br />
二、HTTP协议与状态保�?br />HTTP 协议本��n是无状态的�Q�这与HTTP协议本来的目的是相符的，客户端只需要简单的向服务器��h��下蝲某些文�g�Q�无论是客户端还是服务器都没有必要纪录彼此过�? 的行为，每一�ơ请求之间都是独立的�Q�好比一个顾客和一个自动售货机或者一个普通的�Q�非会员�Ӟ��大卖��Z��间的关系一栗��?br />
然而聪明（或者贪心？�Q�的��Z��很快发现如果能够提供一些按需生成的动态信息会使web变得更加有用�Q�就像给有线电视加上�Ҏ��功能一栗��这�U�需求一斚w��q��HTML逐步��d�� 了表单、脚本、DOM�{�客��L��行�ؓ�Q�另一斚w��在服务器端则出现了CGI规范以响应客��L��的动态请求，作�ؓ传输载体的HTTP协议也添加了文�g上蝲�? cookie�q�些�Ҏ��。其中cookie的作用就是�ؓ了解决HTTP协议无状态的�~�陷所作出的努力。至于后来出现的session机制则是又一�U�在客户端与服务器之间保持状态的解决�Ҏ��?br />
让我们用几个例子来描�q�C��下cookie和session机制之间的区别与联系。笔者曾�l�常�ȝ��一家咖啡店有喝5杯咖啡免费赠一杯咖啡的优惠�Q�然而一�ơ性消�?杯咖啡的��Z��微乎其微�Q�这时就需要某�U�方式来�U�录某位��֮�的消�Ҏ��量。想象一下其实也无外乎下面的几种�Ҏ��Q?br />1、该店的店员很厉宻I��能记住每位顾客的消费数量�Q�只要顾客一走进咖啡店，店员��q��道该怎么对待了。这�U�做法就是协议本�w�支持状态�?br />2、发�l�顾客一张卡片，上面记录着消费的数量，一般还有个有效期限。每�ơ消�Ҏ��Q�如果顾客出�C��张卡片，则此�ơ消费就会与以前或以后的消费相联�p��v来。这�U�做法就是在客户端保持状态�?br />3、发�l�顾客一张会员卡�Q�除了卡号之外什么信息也不纪录，每次消费�Ӟ��如果��֮�出示该卡片，则店员在店里的纪录本上找到这个卡号对应的�U�录��d��一些消费信息。这�U�做法就是在服务器端保持状态�?br />
�? 于HTTP协议是无状态的�Q�而出于种�U�考虑也不希望使之成�ؓ有状态的�Q�因此，后面两种�Ҏ��成为现实的选择。具体来说cookie机制采用的是在客��L��? 持状态的�Ҏ��Q�而session机制采用的是在服务器端保持状态的�Ҏ��。同时我们也看到�Q�由于采用服务器端保持状态的�Ҏ��在客��L��也需要保存一个标识，所以session机制可能需要借助于cookie机制来达��C��存标识的目的�Q�但实际上它�q�有其他选择�?br />
三、理解cookie机制
cookie机制的基本原理就如上面的例子一��L��单，但是�q�有几个问题需要解冻I��“会员卡”如何分发；“会员卡”的内容�Q�以及客户如何��用“会员卡”�?br />
正统的cookie分发是通过扩展HTTP协议来实现的�Q�服务器通过在HTTP的响应头中加上一行特�D�的指示以提�C�浏览器按照指示生成相应的cookie。然而纯�_�的客户端脚本如JavaScript或者VBScript也可以生成cookie�?br />
而cookie 的��用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器��查所有存储的cookie�Q�如果某个cookie所声明的作用范围大于等于将要请求的资源所在的位置�Q�则把该cookie附在��h��资源的HTTP��h��头上发送给服务器。意思是麦当劳的会员卡只能在麦当劳的店里出示�Q�如果某家分店还发行了自 ��q��会员卡，那么�q�这家店的时候除了要出示麦当劳的会员卡，�q�要出示�q�家店的会员卡�?br />
cookie的内容主要包括：名字�Q��|��q�期旉��Q��\径和域�?br />其中域可以指定某一个域比如.google.com�Q�相当于��d��招牌�Q�比如宝�z�公司，也可以指定一个域下的具体某台机器比如www.google.com或者froogle.google.com�Q�可以用飘柔来做比�?br />路径��是跟在域名后面的URL路径�Q�比�?或�?foo�{�等�Q�可以用某飘柔专柜做比�?br />路径与域合在一起就构成了cookie的作用范围�?br />�? 果不讄��q�期旉��Q�则表示�q�个cookie的生命期为浏览器会话期间�Q�只要关闭浏览器�H�口�Q�cookie��消�׃��。这�U�生命期为浏览器会话期的 cookie被称��Z��话cookie。会话cookie一般不存储在硬盘上而是保存在内存里�Q�当然这�U�行为�ƈ不是规范规定的。如果设�|�了�q�期旉��Q�浏�? 器就会把cookie保存到硬盘上�Q�关闭后再次打开��览器，�q�些cookie仍然有效直到��过讑֮�的过期时间�?br />
存储在硬盘上�? cookie 可以在不同的��览器进�E�间�׃�n�Q�比如两个IE�H�口。而对于保存在内存里的cookie�Q�不同的��览器有不同的处理方式。对于IE�Q�在一个打开的窗口上按 Ctrl-N�Q�或者从文�g菜单�Q�打开的窗口可以与原窗口共享，而��用其他方式新开的IE�q�程则不能共享已�l�打开的窗口的内存cookie�Q? 对于 Mozilla Firefox0.8�Q�所有的�q�程和标�{�N��都可以共享同��L��cookie。一般来说是用javascript�? window.open打开的窗口会与原�H�口�׃�n内存cookie。浏览器对于会话cookie的这�U�只认cookie不认人的处理方式�l�常�l�采�? session机制的web应用�E�序开发者造成很大的困扰�?br />
下面��是一个goolge讄��cookie的响应头的例�?br />HTTP/1.1 302 Found
Location: http://www.google.com/intl/zh-CN/
Set-Cookie: PREF=ID=0565f77e132de138:NW=1:TM=1098082649:LM=1098082649:S=KaeaCFPo49RiA_d8; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com
Content-Type: text/html

�q�是使用HTTPLook�q�个HTTP Sniffer软�g来俘��L��HTTP通讯�U�录的一部分

��览器在再次讉K��goolge的资源时自动向外发送cookie

使用Firefox可以很容易的观察现有的cookie的�?br />使用HTTPLook配合Firefox可以很容易的理解cookie的工作原理�?br />

IE也可以设�|�在接受cookie前询�?br />

�q�是一个询问接受cookie的对话框�?br />
四、理解session机制
session机制是一�U�服务器端的机制�Q�服务器使用一�U�类��g��散列表的�l�构�Q�也可能��是使用散列表）来保存信息�?br />
�? �E�序需要�ؓ某个客户端的��h��创徏一个session的时候，服务器首先检查这个客��L��的请求里是否已包含了一个session标识 - �U�Cؓ session id�Q�如果已包含一个session id则说明以前已�l��ؓ此客��L��创徏�q�session�Q�服务器��按照session id把这�? session��索出来��用（如果��索不刎ͼ�可能会新��Z��个）�Q�如果客��L��h��不包含session id�Q�则为此客户端创��Z��个session�q�且�? 成一个与此session相关联的session id�Q�session id的值应该是一个既不会重复�Q�又不容易被扑ֈ�规律以仿造的字符�Ԍ��q�个 session id��被在本�ơ响应中�q�回�l�客��L��保存�?br />
保存�q�个session id的方式可以采用cookie�Q�这样在交互�q�程�? ��览器可以自动的按照规则把这个标识发挥给服务器。一般这个cookie的名字都是类��g��SEEESIONID�Q�而。比如weblogic对于web应用 �E�序生成的cookie�Q�JSESSIONID= ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764�Q�它的名字就�? JSESSIONID�?br />
�׃��cookie可以被�h为的��止�Q�必��L��其他机制以便在cookie被禁止时仍然能够把session id 传递回服务器。经常被使用的一�U�技术叫做URL重写�Q�就是把session id直接附加在URL路径的后面，附加方式也有两种�Q�一�U�是作�ؓURL路径�? 附加信息�Q�表现�Ş式�ؓhttp://...../xxx;jsessionid= ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
另一�U�是作�ؓ查询字符串附加在URL后面�Q�表现�Ş式�ؓhttp://...../xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
�q�两�U�方式对于用��h��说是没有区别的，只是服务器在解析的时候处理的方式不同�Q�采用第一�U�方式也有利于把session id的信息和正常�E�序参数区分开来�?br />��Z��在整个交互过�E�中始终保持状态，��必��d��每个客户端可能请求的路径后面都包含这个session id�?br />
另一�U�技术叫做表单隐藏字�D�c��就是服务器会自动修改表单，��d��一个隐藏字�D�，以便在表单提交时能够把session id传递回服务器。比如下面的表单

在被传递给客户端之前将被改写成

�q�种技术现在已较少应用�Q�笔者接触过的很古老的iPlanet6(SunONE应用服务器的前��n)��׃��用了�q�种技术�?br />实际上这�U�技术可以简单的用对action应用URL重写来代�ѝ�?br />
�? 谈论session机制的时候，常常听到�q�样一�U�误解“只要关闭浏览器�Q�session��消�׃��”。其实可以想象一下会员卡的例子，除非��֮��d��对店家提出销卡，否则店家�l�对不会��L��删除��֮�的资料。对session来说也是一��L��Q�除非程序通知服务器删除一个session�Q�否则服务器会一直保留，�E�序一般都是在用户做log off的时候发个指令去删除session。然而浏览器从来不会��d��在关闭之前通知服务器它��要关闭�Q�因此服务器�Ҏ��不会有机�? 知道��览器已�l�关闭，之所以会有这�U�错觉，是大部分session机制都��用会话cookie来保存session id�Q�而关闭浏览器后这�? session id��消�׃��Q�再�ơ连接服务器时也��无法找到原来的session。如果服务器讄��的cookie被保存到��盘上，或者��用某�U�手�D�|�� 写浏览器发出的HTTP��h��_��把原来的session id发送给服务器，则再�ơ打开��览器仍然能够找到原来的session�?br />
恰恰是由于关闭浏览器不会��D��session被删除，�q��服务器�ؓseesion讄��了一个失效时��_��当距��d��L��上一�ơ��用session的时间超�q�这个失效时间时�Q�服务器��可以认为客��L��已经停止了活动，才会把session删除以节省存储空间�?br />
五、理解javax.servlet.http.HttpSession
HttpSession是Java�q�_��对session机制的实现规范，因�ؓ它仅仅是个接口，具体到每个web应用服务器的提供商，除了对规范支持之外，仍然会有一些规范里没有规定的细微差异。这里我们以BEA的Weblogic Server8.1作�ؓ例子来演�C��?br />
�? 先，Weblogic Server提供了一�p�d��的参数来控制它的HttpSession的实玎ͼ�包括使用cookie的开关选项�Q��用URL重写的开�? 选项�Q�session持久化的讄��Q�session失效旉��的设�|�，以及针对cookie的各�U�设�|�，比如讄��cookie的名字、�\径、域�Q? cookie的生存时间等�?br />
一般情况下�Q�session都是存储在内存里�Q�当服务器进�E�被停止或者重启的时候，内存里的session 也会被清�I�，如果讄��了session的持久化�Ҏ��，服务器就会把session保存到硬盘上�Q�当服务器进�E�重新启动或�q�些信息��能够被再次使用�Q? Weblogic Server支持的持久性方式包括文件、数据库、客��L��cookie保存和复制�?br />
复制严格说来不算持久化保存，因�ؓsession实际上还是保存在内存里，不过同样的信息被复制到各个cluster内的服务器进�E�中�Q�这样即使某个服务器�q�程停止工作也仍然可以从其他�q�程中取得session�?br />
cookie生存旉��的设�|�则会媄响浏览器生成的cookie是否是一个会话cookie。默认是使用会话cookie。有兴趣的可以用它来试验我们在第四节里提到的那个误解�?br />
cookie的�\径对于web应用�E�序来说是一个非帔R��要的选项�Q�Weblogic Server对这个选项的默认处理方式��得它与其他服务器有明昄��区别。后面我们会专题讨论�?br />
关于session的设�|�参考[5] http://e-docs.bea.com/wls/docs70/webapp/weblogic_xml.html#1036869

六、HttpSession常见问题
�Q�在本小节中session的含义�ؓ⑤和⑥的混合�Q?br />

1、session在何时被创徏
一个常见的误解是以为session在有客户端访问时��p��创徏�Q�然而事实是直到某server端程序调�? HttpServletRequest.getSession(true)�q�样的语句时才被创徏�Q�注意如果JSP没有昄��的��用�?lt;% @page session="false"%> 关闭session�Q�则JSP文�g在编译成Servlet时将会自动加上这样一条语�? HttpSession session = HttpServletRequest.getSession(true);�q�也是JSP中隐含的 session对象的来历�?br />
�׃��session会消耗内存资源，因此�Q�如果不打算使用session�Q�应该在所有的JSP中关闭它�?br />
2、session何时被删�?br />�l�合前面的讨论，session在下列情况下被删除a.�E�序调用HttpSession.invalidate();或b.距离上一�ơ收到客��L��发送的session id旉��间隔��过了session的超时设�|?或c.服务器进�E�被停止�Q�非持久session�Q?br />
3、如何做到在��览器关闭时删除session
严格的讲�Q�做不到�q�一炏V��可以做一点努力的办法是在所有的客户端页面里使用javascript代码window.oncolose来监视浏览器的关闭动作，然后向服务器发送一个请求来删除session。但是对于浏览器崩溃或者强行杀死进�E�这些非常规手段仍然无能为力�?br />
4、有个HttpSessionListener是怎么回事
�? 可以创徏�q�样的listener�ȝ��控session的创建和销毁事�Ӟ��使得在发生这��L��事�g时你可以做一些相应的工作。注意是session的创建和销毁动作触发listener�Q�而不是相反。类似的与HttpSession有关的listener�q�有 HttpSessionBindingListener�Q�HttpSessionActivationListener�? HttpSessionAttributeListener�?br />
5、存攑֜�session中的对象必须是可序列化的�?br />不是必需的。要求对象可序列化只是�ؓ了session能够在集��中被复制或者能够持久保存或者在必要时server能够暂时把session交换出内存。在 Weblogic Server的session中放�|�一个不可序列化的对象在控制��C��会收��C��个警告。我所用过的某个iPlanet版本如果 session中有不可序列化的对象�Q�在session销毁时会有一个Exception�Q�很奇怪�?br />
6、如何才能正��的应付客户端禁止cookie的可能�?br />�Ҏ��有的URL使用URL重写�Q�包括超链接�Q�form的action�Q�和重定向的URL�Q�具体做法参见[6]
http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770

7、开两个��览器窗口访问应用程序会使用同一个session�q�是不同的session
参见�W�三��节对cookie的讨论，对session来说是只认id不认人，因此不同的浏览器�Q�不同的�H�口打开方式以及不同的cookie存储方式都会对这个问题的�{�案有媄响�?br />
8、如何防止用��h��开两个��览器窗口操作导致的session混�ؕ
�q? 个问题与防止表单多次提交是类似的�Q�可以通过讄��客户端的令牌来解冟뀂就是在服务器每�ơ生成一个不同的id�q�回�l�客��L��Q�同时保存在session里，�? ��L��提交表单时必��L��q�个id也返回服务器�Q�程序首先比较返回的id与保存在session里的值是否一��_��如果不一致则说明本次操作已经被提交过了。可以参看《J2EE核心模式》关于表�C�层模式的部分。需要注意的是对于��用javascript window.open打开的窗口，一般不讄��q�个id�Q? 或者��用单独的id�Q�以防主�H�口无法操作�Q�徏议不要再window.open打开的窗口里做修�Ҏ��作，�q�样��可以不用设�|��?br />
9、�ؓ什么在Weblogic Server中改变session的值后要重新调用一�ơsession.setValue
做这个动作主要是��Z��在集��环境中提示Weblogic Server session中的值发生了改变�Q�需要向其他服务器进�E�复制新的session倹{�?br />
10、�ؓ什么session不见�?br />�? 除session正常失效的因素之外，服务器本�w�的可能性应该是微乎其微的，虽然�W�者在iPlanet6SP1加若�q�补丁的Solaris版本上倒也遇到 �q�；��览器插件的可能性次之，�W�者也遇到�q?721插�g造成的问题；理论上防火墙或者代理服务器在cookie处理上也有可能会出现问题�?br />出现�q�一问题的大部分原因都是�E�序的错误，最常见的就是在一个应用程序中去访问另外一个应用程序。我们在下一节讨��个问题�?br />
七、跨应用�E�序的session�׃�n

�? 常有�q�样的情况，一个大��目被分割成若干��项目开发，��Z��能够互不�q�扰�Q�要求每个小��目作�ؓ一个单独的web应用�E�序开发，可是��C��最后突然发现某几个��? ��目之间需要共享一些信息，或者想使用session来实现SSO(single sign on)�Q�在session中保存login的用户信息，最�? 然的要求是应用程序间能够讉K��彼此的session�?br />
然而按照Servlet规范�Q�session的作用范围应该仅仅限于当前应用程�? 下，不同的应用程序之间是不能够互相访问对方的session的。各个应用服务器从实际效果上都遵守了�q�一规范�Q�但是实现的�l�节却可能各有不同，因此解决跨应用程序session�׃�n的方法也各不相同�?br />
首先来看一下Tomcat是如何实现web应用�E�序之间session的隔��ȝ��Q�从 Tomcat讄��的cookie路径来看�Q�它对不同的应用�E�序讄��的cookie路径是不同的�Q�这样不同的应用�E�序所用的session id是不�? 的，因此即��在同一个浏览器�H�口里访问不同的应用�E�序�Q�发送给服务器的session id也可以是不同的�?br />

�Ҏ��q�个�Ҏ��，我们可以推测Tomcat中session的内存结构大致如下�?br />

�W? 者以前用�q�的iPlanet也采用的是同��L��方式�Q�估计SunONE与iPlanet之间不会有太大的差别。对于这�U�方式的服务器，解决的思�\很简单，�? 际实行�v来也不难。要么让所有的应用�E�序�׃�n一个session id�Q�要么让应用�E�序能够获得其他应用�E�序的session id�?br />
iPlanet中有一�U�很��单的�Ҏ��来实现共享一个session id�Q�那��是把各个应用程序的cookie路径都设�?�Q�实际上应该�?NASApp�Q�对于应用程序来讲它的作用相当于根）�?br />
/NASApp

需要注意的是，操作�׃�n的session应该遵��@一些编�E�约定，比如在session attribute名字的前面加上应用程序的前缀�Q��? setAttribute("name", "neo")变成setAttribute("app1.name", "neo")�Q�以防止命名�I�间�? �H�，��D��互相覆盖�?br />

在Tomcat中则没有�q�么方便的选择。在Tomcat版本3上，我们�q�可以有一些手�D�|��׃�n session。对于版�?以上的Tomcat�Q�目前笔者尚未发现简单的办法。只能借助于第三方的力量，比如使用文�g、数据库、JMS或者客��L�� cookie�Q�URL参数或者隐藏字�D늭�手段�?br />
我们再看一下Weblogic Server是如何处理session的�?br />

�? 截屏画面上可以看到Weblogic Server�Ҏ��有的应用�E�序讄��的cookie的�\径都�?�Q�这是不是意味着在Weblogic Server�? 默认的就可以�׃�nsession了呢�Q�然而一个小实验卛_��证明即��不同的应用程序��用的是同一个session�Q�各个应用程序仍然只能访问自己所讄��的那些属性。这说明Weblogic Server中的session的内存结构可能如�?br />

对于�q�样一�U�结构，�? session机制本��n上来解决session�׃�n的问题应该是不可能的了。除了借助于第三方的力量，比如使用文�g、数据库、JMS或者客��L�� cookie�Q�URL参数或者隐藏字�D늭�手段�Q�还有一�U�较为方便的做法�Q�就是把一个应用程序的session攑ֈ�ServletContext中，�q�样另外一个应用程序就可以从ServletContext中取得前一个应用程序的引用。示例代码如下，

应用�E�序A
context.setAttribute("appA", session);

应用�E�序B
contextA = context.getContext("/appA");
HttpSession sessionA = (HttpSession)contextA.getAttribute("appA");

值得注意的是�q�种用法不可�U�L��Q�因为根据ServletContext的JavaDoc�Q�应用服务器可以处于安全的原因对于context.getContext("/appA");�q�回�I��|��以上做法在Weblogic Server 8.1中通过�?br />
�? 么Weblogic Server��Z��么要把所有的应用�E�序的cookie路径都设�?呢？原来是�ؓ了SSO�Q�凡是共享这个session的应用程序都�? 以共享认证的信息。一个简单的实验��可以证明这一点，修改首先��d��的那个应用程序的描述�W�weblogic.xml�Q�把cookie路径修改�? /appA 讉K��另外一个应用程序会重新要求��d��Q�即使是反过来，先访问cookie路径�?的应用程序，再访问修改过路径的这个，虽然不再提示��d��Q�但是登录的用户信息也会丢失。注意做�q�个实验时认证方式应该��用FORM�Q�因为浏览器和web服务器对basic认证方式有其他的处理方式�Q�第二次��h��的认证不是通过 session来实现的。具体请参看[7] secion 14.8 Authorization�Q�你可以修改所附的�C�Z��E�序来做�q�些试验�?br />
八、�ȝ��
session机制本��n�q�不复杂�Q�然而其实现和配�|�上的灵�z�L��却使得具体情况复杂多变。这也要求我们不能把仅仅某一�ơ的�l�验或者某一个浏览器�Q�服务器的经验当作普遍适用的经验，而是始终需要具体情况具体分析�?br />�? 要：虽然session机制在web应用�E�序中被采用已经很长旉��了，但是仍然有很多�h不清楚session机制的本质，以至不能正确的应用这一技术。本文将详细讨论session的工作机制�ƈ且对在Java web application中应用session机制时常见的问题作出解答�?img src ="http://www.aygfsteel.com/wadise/aggbug/45273.html" width = "1" height = "1" />

wadise 2006-05-09 20:26 发表评论

Adobe Acrobat 7.0下蝲地址�Q�不是Adobe Acrobat Reader

wadise — Fri, 03 Mar 2006 08:53:00 GMT

�q�个软�g可以对PDF�q�行创徏�Q�编辑，加注释，评语�{�等�?BR>URL http://219.149.54.89/Software/SoftDown.asp?ID=33

wadise 2006-03-03 16:53 发表评论

wadise — Thu, 02 Mar 2006 00:55:00 GMT

如何把Hibernate2.1升��到Hibernate3.0�Q?

选自<<�_�N��Hibernate�Q�Java对象持久化技术详�?gt;> 作者：孙卫�?/FONT> 来源:www.javathinker.org
如果转蝲�Q�请标明出处�Q�谢�?BR>

1.1 Hibernate API 变化
 1.1.1 包名
 1.1.2 org.hibernate.classic�?
1.1.3 Hibernate所依赖的第三方软�g�?/FONT>
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�c?
1.1.11 PersistentEnum�c?
1.1.12 对Blob 和Clob的支�?
1.1.13 Hibernate中供扩展的API的变�?
1.2 元数据的变化
 1.2.1 ��索策�?
1.2.2 对象标识�W�的映射
 1.2.3 集合映射
 1.2.4 DTD
1.3 查询语句的变�?
1.3.1 indices()和elements()函数

��管Hibernate 3.0 与Hibernate2.1的源代码是不兼容的，但是当Hibernate开发小�l�在设计Hibernate3.0�Ӟ��为简化升�U�Hibernate版本作了周到的考虑。对于现有的��Z��Hibernate2.1的Java��目�Q�可以很方便的把它升�U�到Hibernate3.0�?BR>
本文描述了Hibernate3.0版本的新变化�Q�Hibernate3.0版本的变化包括三个方面：
�Q?�Q�API的变化，它将影响到Java�E�序代码�?BR>�Q?�Q�元数据�Q�它��媄响到对象-关系映射文�g�?BR>�Q?�Q�HQL查询语句�?BR>
值得注意的是�Q?Hibernate3.0�q�不会完全取代Hibernate2.1。在同一个应用程序中�Q�允许Hibernate3.0和Hibernate2.1�q�存�?BR>
1.1 Hibernate API 变化

1.1.1 包名

Hibernate3.0的包的根路径�? “org.hibernate�?�Q�而在Hibernate2.1中�ؓ“net.sf.hibernate”。这一命名变化使得Hibernate2.1和Hibernate3.0能够同时在同一个应用程序中�q�行�?BR>
如果希望把已有的应用升��到Hibernate3.0�Q�那么升�U�的�W�一步是把Java源程序中的所有“net.sf.hibernate”替换�ؓ“org.hibernate”�?BR>
Hibernate2.1中的“net.sf.hibernate.expression”包被改名�ؓ“org.hibernate.criterion”。假如应用程序��用了Criteria API�Q�那么在升��的过�E�中�Q�必��L��Java源程序中的所有“net.sf.hibernate.expression”替换�ؓ“org.hibernate.criterion”�?BR>
如果应用使用了除Hibernate以外的其他外部��Y�Ӟ��而这个外部��Y件又引用了Hibernate的接口，那么在升�U�时必须十分��心。例如EHCache拥有自己的CacheProvider�Q?net.sf.ehcache.hibernate.Provider�Q�在�q�个�c�M��引用了Hibernate2.1中的接口�Q�在升��应用�Ӟ��可以采用以下办法之一来升�U�EHCache:

�Q?�Q�手工修改net.sf.ehcache.hibernate.Provider�c�，使它引用Hibernate3.0中的接口�?BR>�Q?�Q�等到EHCache软�g本��n升��Z��用Hibernate3.0后，使用新的EHCache软�g�?BR>�Q?�Q��用Hibernate3.0中内�|�的CacheProvider�Q�org.hibernate.cache.EhCacheProvider�?BR>
1.1.2 org.hibernate.classic�?BR>
Hibernate3.0把一些被废弃的接口都转移到org.hibernate.classic中�?BR>
1.1.3 Hibernate所依赖的第三方软�g�?BR>
在Hibernate3.0的��Y件包的lib目录下的README.txt文�g中，描述了Hibernate3.0所依赖的第三方软�g包的变化�?BR>
1.1.4 异常模型

在Hibernate3.0中，HibernateException异常以及它的所有子�c�都�l�承了java.lang.RuntimeException。因此在�~�译�Ӟ��~�译器不会再��查HibernateException�?BR>
1.1.5 Session接口

在Hibernate3.0中，原来Hibernate2.1的Session接口中的有些基本�Ҏ��也被废弃�Q�但��Z��化升�U�，�q�些�Ҏ��依然是可用的�Q�可以通过org.hibernate.classic.Session子接口来讉K��它们�Q�例如：

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

在Hibernate3.0中，org.hibernate.classic.Session接口�l�承了org.hibernate.Session接口�Q�在org.hibernate.classic.Session接口中包含了一�p�d��被废弃的�Ҏ��Q�如find()、interate()�{�。SessionFactory接口的openSession()�Ҏ��q�回org.hibernate.classic.Session�c�d��的实例。如果希望在�E�序中完全��用Hibernate3.0�Q�可以采用以下方式创建Session实例�Q?BR>
org.hibernate.Session session=sessionFactory.openSession();

如果是对已有的程序进行简单的升��Q��ƈ且希望仍然调用Hibernate2.1中Session的一些接口，可以采用以下方式创徏Session实例�Q?BR>
org.hibernate.classic.Session session=sessionFactory.openSession();

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

Hibernate3.0一律采用createQuery()�Ҏ��来执行所有的查询语句�Q�采用DELETE 查询语句来执行批量删除，采用merge()�Ҏ��来替�?saveOrUpdateCopy()�Ҏ��?/P>

提示�Q�在Hibernate2.1中，Session的delete()�Ҏ��有几�U�重载�Ş式，其中参数为HQL查询语句的delete()�Ҏ��在Hibernate3.0中被废弃�Q�而参��CؓOjbect�c�d��的的delete()�Ҏ��依然被支持。delete(Object o)�Ҏ��用于删除参数指定的对象，该方法支持��联删除�?/I>

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

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执行扚w��删除的程序代码：

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接口来完成相同的功能�?BR>
1.1.7 Lifecycle �?Validatable 接口

Lifecycle和Validatable 接口被废弃，�q�且被移到org.hibernate.classic包中�?BR>
1.1.8 Interceptor接口

在Interceptor 接口中加入了两个新的�Ҏ��?用户创徏的Interceptor实现�c�d��升��的过�E�中�Q�需要�ؓ�q�两个新�Ҏ��提供�Ҏ��体�ؓ�I�的实现。此外，instantiate()�Ҏ��的参��C��了修改，isUnsaved()�Ҏ��被改名�ؓisTransient()�?BR>
1.1.9 UserType和CompositeUserType接口

在UserType和CompositeUserType接口中都加入了一些新的方法，�q�两个接口被�U�d��org.hibernate.usertype包中�Q�用户定义的UserType和CompositeUserType实现�c�d��d��现这些新�Ҏ��?/P>
Hibernate3.0提供了ParameterizedType接口�Q�用于更好的重用用户自定义的�c�d��?/P>
1.1.10 FetchMode�c?BR>
FetchMode.LAZY �?FetchMode.EAGER被废弃。取而代之的分别为FetchMode.SELECT 和FetchMode.JOIN�?BR>
1.1.11 PersistentEnum�c?BR>
PersistentEnum被废弃�ƈ删除。已�l�存在的应用应该采用UserType来处理枚丄��型�?BR>
1.1.12 对Blob 和Clob的支�?BR>
Hibernate对Blob和Clob实例�q�行了包装，使得那些拥有Blob或Clob�c�d��的属性的�cȝ��实例可以被游��R��序列化或反序列化，以及传递到merge()�Ҏ��中�?BR>
1.1.13 Hibernate中供扩展的API的变�?BR>
org.hibernate.criterion�?org.hibernate.mapping�?org.hibernate.persister和org.hibernate.collection 包的�l�构和实现发生了重大的变化。多数基于Hibernate
2.1 的应用不依赖于这些包�Q�因此不会被影响。如果你的应用扩展了�q�些包中的类�Q�那么必��非常小心的对受影响的程序代码进行升�U��?BR>
1.2 元数据的变化

1.2.1 ��索策�?BR>
在Hibernate2.1中，lazy属性的默认��gؓ“false”，而在Hibernate3.0中，lazy属性的默认��gؓ“true”。在升��映射文�g�Ӟ��如果原来的映��文件中的有兛_��素，�?lt;set>�?lt;class>�{�没有显式设�|�lazy属性，那么必须把它们都昑ּ�的设�|��ؓlazy=“true”。如果觉得这�U�升�U�方式很�ȝ��Q�可以采取另一��单的升��方式�Q�在元素中设�|? default-lazy=“false”�?

1.2.2 对象标识�W�的映射

unsaved-value属性是可选的�Q�在多数情况下，Hibernate3.0��把unsaved-value="0" 作�ؓ默认倹{�?BR>
在Hibernate3.0中，当��用自然主键和游离对象�Ӟ��不再��实现Interceptor.isUnsaved()�Ҏ��?如果没有讄��q�个�Ҏ��Q�当Hibernate3.0无法区分对象的状态时�Q�会查询数据库，来判断这个对象到底是临时对象�Q�还是游��d��象。不�q�，昑ּ�的��用Interceptor.isUnsaved()�Ҏ��会获得更好的性能�Q�因��可以减少Hibernate直接讉K��数据库的�ơ数�?BR>
1.2.3 集合映射

元素在某些情况下�?lt;list-index>�?lt;map-key>元素替代。此外，Hibernate3.0�?lt;map-key-many-to-many> 元素来替代原来的.元素�Q�用元素来替代原来的元素�?BR>
1.2.4 DTD

对象-关系映射文�g中的DTD文档�Q�由原来的：
http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd
改�ؓ�Q?BR>http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd

1.3 查询语句的变�?BR>
Hibernate3.0 采用新的��Z��ANTLR的HQL/SQL查询��译器，不过�Q�Hibernate2.1的查询翻译器也依然存在。在Hibernate的配�|�文件中�Q�hibernate.query.factory_class属性用来选择查询��译器。例如：
�Q?�Q�选择Hibernate3.0的查询翻译器�Q?BR>hibernate.query.factory_class= org.hibernate.hql.ast.ASTQueryTranslatorFactory
�Q?�Q�选择Hibernate2.1的查询翻译器
hibernate.query.factory_class= org.hibernate.hql.classic.ClassicQueryTranslatorFactory

提示�Q�ANTLR是用�U�Java语言�~�写出来的一个编译工��P��它可生成Java语言或者是C++的词法和语法分析器，�q�可产生语法分析树�ƈ对该树进行遍历。ANTLR�׃��是纯Java的，因此可以安装在�Q意��^��C��Q�但是需要JDK的支持�?/I>

Hibernate开发小�l�尽力保证Hibernate3.0的查询翻译器能够支持Hibernate2.1的所有查询语句。不�q�，对于许多已经存在的应用，在升�U�过�E�中�Q�也不妨仍然使用Hibernate2.1的查询翻译器�?BR>值得注意的是�Q?Hibernate3.0的查询翻译器存在一个Bug�Q�不支持某些theta-style�q�结查询方言�Q�如Oracle8i的OracleDialect方言、Sybase11Dialect。解册��一问题的办法有两种�Q�（1�Q�改��Z��用支持ANSI-style�q�结查询的方�a��Q�如 Oracle9Dialect,�Q?�Q�如果升�U�的时候遇到这一问题�Q�那么还是改��Z��用Hibernate2.1的查询翻译器�?BR>
1.3.1 indices()和elements()函数

在HQL的select子句中废弃了indices()和elements()函数�Q�因��两个函数的语法很让用戯��解，可以用显式的�q�接查询语句来替�?select elements(...) 。而在HQL的where子句中，仍然可以使用elements()函数�?BR>

wadise 2006-03-02 08:55 发表评论

wadise — Wed, 14 Dec 2005 04:08:00 GMT

下面是JUnit的测试代�?��试能通过)�Q?/P>

1        User user = new User();
2        assertTrue(user.getClass().isAssignableFrom(User.class));
3        assertFalse(user.getClass().isAssignableFrom(Actor.class));
4        assertFalse(user.getClass().isAssignableFrom(IUser.class));
5        assertFalse(user.getClass().isAssignableFrom(IActor.class));
6
7        assertTrue(user instanceof User);
8        assertTrue(user instanceof Actor);
9        assertTrue(user instanceof IUser);
10       assertTrue(user instanceof IActor);

�c�M��c�M��间的层次关系是：

User extend Actor implements IUser

从上面可以看出isAssignableFrom和instanceof的不同之处�?/FONT>

wadise 2005-12-14 12:08 发表评论