僅為個人理解.請指正
Hibernate Session, 其作用無需多言.
在運用中為避免資源消耗,一般都會手動封裝一個HibernateUtil類(未使用Spring管理的前提下).
該類的作用使Hibernate加載配置文件config, 創(chuàng)建sessionFactory等只運行一次.
實際運用中,經(jīng)常需要將當(dāng)前線程和session綁定.一般的用法為使用ThreadLocal: 在HibernateUtil類中封裝hibernate的管理.通過openSession取得
session,并將其放入ThreadLocal變量中. 這樣業(yè)務(wù)邏輯中僅需通過工具類取得當(dāng)前線程對應(yīng)的session.使用完畢后,調(diào)用工具類closeSession方法將
session關(guān)閉,當(dāng)前線程的ThreadLocal變量置為NULL. 保證線程歸還線程池復(fù)用后,ThreadLocal為空,以免出現(xiàn)導(dǎo)致其他線程訪問到本線程變量.
而后,Hibernate的SessionFactory提供獲取session的新方法getCurrentSession (獲得與當(dāng)前線程綁定的session). 內(nèi)部通過代理封裝,此方式得到的session
不僅和當(dāng)前線程綁定,也無需手動開關(guān). 默認(rèn)在事務(wù)提交之后,session自動關(guān)閉. 需注意的是,必須在事務(wù)開啟的前提之下才可使用此種方式獲得的session.
此外hibernate.cfg.xml配置文件中也許配置


------------------------------以下內(nèi)容為工地資料-------------------------------------------------------------------------------
1  OpenSession : 手動打開,需手動關(guān)閉.[所以代碼中充斥著try catch --sf.openSession --打開事務(wù),提交-回滾 finall關(guān)閉session的代碼]

http://space.itpub.net/9252210/viewspace-594453

今天在做數(shù)據(jù)導(dǎo)出的時候，由于用戶名的密碼使用的是特殊字符，所以遇到了錯誤代碼：“EXP-00056: 遇到 ORACLE 錯誤 12154”，網(wǎng)上查找原因，需要用引號擴起來，但是os不同，方式也不同:

    windows os: exp username/"""password"""@devdb --3個雙引號擴密碼

    linux/unix os: exp 'username/"password"@devdb' --1個雙引號擴密碼，1個單引號擴全部

    實驗結(jié)果如下：
1.創(chuàng)建帶有特殊字符密碼的用戶
C:\Documents and Settings\Home>sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 - Production on 星期四 5月 7 17:37:36 2009
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
SQL> connsys/oracle@devdbas sysdba
已連接。
SQL> create user exp identified by "12345!@#$%";
用戶已創(chuàng)建。
SQL> grant connect, resource to exp;
授權(quán)成功。
SQL> conn exp/"12345!@#$%"@devdb2
已連接。
SQL> create table table1 as select * from dual;
表已創(chuàng)建。
SQL> exit
2.windows os導(dǎo)出測試
C:\Documents and Settings\Home>expexp/12345!@#$%@devdbfile=c:\exp.dmp wner=exp
Export: Release 9.2.0.1.0 - Production on 星期四 5月 7 17:39:42 2009
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
EXP-00056: 遇到 ORACLE 錯誤 12154
ORA-12154: TNS: 無法處理服務(wù)名
EXP-00000: 導(dǎo)出終止失敗
C:\Documents and Settings\Home>exp exp/"12345!@#$%"@devdb2file=c:\exp.dmp wner=exp
Export: Release 9.2.0.1.0 - Production on 星期四 5月 7 17:39:57 2009
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
EXP-00056: 遇到 ORACLE 錯誤 12154
ORA-12154: TNS: 無法處理服務(wù)名
EXP-00000: 導(dǎo)出終止失敗
C:\Documents and Settings\Home>exp exp/"""12345!@#$%"""@devdb2file=c:\exp.dmp wner=exp
Export: Release 9.2.0.1.0 - Production on 星期四 5月 7 17:41:54 2009
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
連接到: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
已導(dǎo)出 ZHS16GBK 字符集和 AL16UTF16 NCHAR 字符集
. 正在導(dǎo)出 pre-schema 過程對象和操作
. 正在導(dǎo)出用戶 EXP 的外部函數(shù)庫名稱
. 導(dǎo)出 PUBLIC 類型同義詞
. 導(dǎo)出私有類型同義詞
. 正在導(dǎo)出用戶 EXP 的對象類型定義
即將導(dǎo)出 EXP 的對象 ...
. 正在導(dǎo)出數(shù)據(jù)庫鏈接
. 正在導(dǎo)出序號
. 正在導(dǎo)出群集定義
. 即將導(dǎo)出 EXP 的表通過常規(guī)路徑 ...
. . 正在導(dǎo)出表                          TABLE1          1 行被導(dǎo)出
. 正在導(dǎo)出同義詞
. 正在導(dǎo)出視圖
. 正在導(dǎo)出存儲的過程
. 正在導(dǎo)出運算符
. 正在導(dǎo)出引用完整性約束條件
. 正在導(dǎo)出觸發(fā)器
. 正在導(dǎo)出索引類型
. 正在導(dǎo)出位圖, 功能性索引和可擴展索引
. 正在導(dǎo)出后期表活動
. 正在導(dǎo)出實體化視圖
. 正在導(dǎo)出快照日志
. 正在導(dǎo)出作業(yè)隊列
. 正在導(dǎo)出刷新組和子組
. 正在導(dǎo)出維
. 正在導(dǎo)出 post-schema 過程對象和操作
. 正在導(dǎo)出統(tǒng)計
在沒有警告的情況下成功終止導(dǎo)出。

3.linux/unix os導(dǎo)出測試
[oracle@rac2 ~]$ expexp/12345!@#$%@devdbfile=./exp.dmp wner=exp
-bash:!@#$%@devdb: event not found
[oracle@rac2 ~]$ exp exp/"""12345!@#$%"""@devdbfile=./exp.dmp wner=exp
-bash:!@#$%"""@devdb: event not found
[oracle@rac2 ~]$exp 'exp/"12345!@#$%"@devdb'file=./exp.dmp wner=exp 
Export: Release 10.2.0.4.0 - Production on Thu May 7 19:21:32 2009 
Copyright (c) 1982, 2007, Oracle.  All rights reserved. 
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses ZHS16GBK character set (possible charset conversion)
. exporting pre-schema procedural objects and actions
. exporting foreign function library names for user EXP
. exporting PUBLIC type synonyms
. exporting private type synonyms
. exporting object type definitions for user EXP
About to export EXP's objects ...
. exporting database links
. exporting sequence numbers
. exporting cluster definitions
. about to export EXP's tables via Conventional Path ...
. . exporting table                         TABLE1          1 rows exported
. exporting synonyms
. exporting views
. exporting stored procedures
. exporting operators
. exporting referential integrity constraints
. exporting triggers
. exporting indextypes
. exporting bitmap, functional and extensible indexes
. exporting posttables actions
. exporting materialized views
. exporting snapshot logs
. exporting job queues
. exporting refresh groups and children
. exporting dimensions
. exporting post-schema procedural objects and actions
. exporting statistics
Export terminated successfully without warnings.

1，什么是Servlet
2，Servlet有什么作用
3，Servlet的生命周期
4，Servlet怎么處理一個請求
5，Servlet與JSP有什么區(qū)別
6，Servlet里的cookie技術(shù)
7，Servlet里的過濾器
8，Servlet里的監(jiān)聽器

 

一，什么是Servlet？

Servlet是一個Java編寫的程序，此程序是基于Http協(xié)議的，在服務(wù)器端運行的(如tomcat)，

 

是按照Servlet規(guī)范編寫的一個Java類。

二，Servlet有什么作用？

主要是處理客戶端的請求并將其結(jié)果發(fā)送到客戶端。

三，Servlet的生命周期？

Servlet的生命周期是由Servlet的容器來控制的，它可以分為3個階段;初始化，運行，銷毀。

初始化階段：

1，Servlet容器加載servlet類，把servlet類的.class文件中的數(shù)據(jù)讀到內(nèi)存中。

2，然后Servlet容器創(chuàng)建一個ServletConfig對象。ServletConfig對象包含了Servlet的初始化配置信息。

3，Servlet容器創(chuàng)建一個servlet對象。

4，Servlet容器調(diào)用servlet對象的init方法進(jìn)行初始化。

運行階段：

當(dāng)servlet容器接收到一個請求時，servlet容器會針對這個請求創(chuàng)建servletRequest和servletResponse對象。

 

然后調(diào)用service方法。并把這兩個參數(shù)傳遞給service方法。Service方法通過servletRequest對象獲得請求的

 

信息。并處理該請求。再通過servletResponse對象生成這個請求的響應(yīng)結(jié)果。然后銷毀servletRequest和

 

servletResponse對象。我們不管這個請求是post提交的還是get提交的，最終這個請求都會由service方法來處理。

 

銷毀階段：

當(dāng)Web應(yīng)用被終止時，servlet容器會先調(diào)用servlet對象的destrory方法，然后再銷毀servlet對象，

 

同時也會銷毀與servlet對象相關(guān)聯(lián)的servletConfig對象。我們可以在destroy方法的實現(xiàn)中，釋放

 

servlet所占用的資源，如關(guān)閉數(shù)據(jù)庫連接，關(guān)閉文件輸入輸出流等。

在這里該注意的地方：

在servlet生命周期中，servlet的初始化和和銷毀階段只會發(fā)生一次，而service方法執(zhí)行的次數(shù)則取決于servlet被客戶

 

端訪問的次數(shù)

 

 

四，Servlet怎么處理一個請求？

當(dāng)用戶發(fā)送一個請求到某個Servlet的時候，Servlet容器會創(chuàng)建一個ServletRequst和ServletResponse對象。

 

在ServletRequst對象中封裝了用戶的請求信息，然后Servlet容器把ServletRequst和ServletResponse對象

 

傳給用戶所請求的Servlet，Servlet把處理好的結(jié)果寫在ServletResponse中，然后Servlet容器把響應(yīng)結(jié)果傳

 

給用戶。

 

五，Servlet與JSP有什么區(qū)別？

1，jsp經(jīng)編譯后就是servlet，也可以說jsp等于servlet。

2，jsp更擅長頁面(表現(xiàn))。servlet更擅長邏輯編輯。 (最核心的區(qū)別)。

3，在實際應(yīng)用中采用Servlet來控制業(yè)務(wù)流程,而采用JSP來生成動態(tài)網(wǎng)頁.在struts框架中,

 

JSP位于MVC設(shè)計模式的視圖層,而Servlet位于控制層。

 

六，Servlet里的cookie技術(shù)？

cookies是一種WEB服務(wù)器通過瀏覽器在訪問者的硬盤上存儲信息的手段，是由Netscape公司開發(fā)出來的。

cookie技術(shù)的好處：

    1，Cookie有效期限未到時，Cookie能使用戶在不鍵入密碼和用戶名的情況下進(jìn)入曾經(jīng)瀏覽過的一些站點。

    2，Cookie能使站點跟蹤特定訪問者的訪問次數(shù)、最后訪問時間和訪問者進(jìn)入站點的路徑。
   
創(chuàng)建一個cookie

 

使用cookie

 

七，Servlet里的過濾器？

過濾器的主要作用

1，任何系統(tǒng)或網(wǎng)站都要判斷用戶是否登錄。

2，網(wǎng)絡(luò)聊天系統(tǒng)或論壇，功能是過濾非法文字

3，統(tǒng)一解決編碼

(2)怎么創(chuàng)建一個過濾器：

 

1，生成一個普通的class類，實現(xiàn)Filter接口(javax.servlet.Filter;)。

2，重寫接口里面的三個方法：init，doFilter，destroy。

3，然后在web.xml配置過濾器。

八，Servlet里的監(jiān)聽器？

監(jiān)聽器的作用：自動執(zhí)行一些操作。

三種servlet監(jiān)聽器:

 

對request的監(jiān)聽。對session的監(jiān)聽。對application的監(jiān)聽。

怎么創(chuàng)建一個session監(jiān)聽器：

1，生成一個普通的class類，如果是對session的監(jiān)聽，則實現(xiàn)HttpSessionListener。

2，然后重寫里面的五個方法:

 

http://www.jdon.com/artichect/state.htm

板橋里人 http://www.jdon.com 2006/1/2（轉(zhuǎn)載請保留）

　　這是一個實戰(zhàn)中非常重要但是容易被忽視的概念，說它重要，是因為它比數(shù)據(jù)庫重要；說它容易被忽視也是同樣的原因，它經(jīng)常被數(shù)據(jù)庫概念替代。

　　如果你經(jīng)驗和經(jīng)歷中沒有狀態(tài)這個概念，極端地說：可能你的Java系統(tǒng)經(jīng)驗還未積累到一定程度，狀態(tài)是每個Java程序員深入Java系統(tǒng)后必然碰到的問題。

　　本文我想試圖表達(dá)的是：狀態(tài)分兩種：活動的狀態(tài)對象和持久化的狀態(tài)。而數(shù)據(jù)庫中的數(shù)據(jù)只是狀態(tài)的一種持久化結(jié)果，而Java系統(tǒng) 運行時，我們更多的可能是和一種活動的狀態(tài)打交道，這種活動的狀態(tài)存在內(nèi)存中，而不是持久化到硬盤上，當(dāng)然，需要時你可以通過數(shù)據(jù)庫/文件持久化到硬盤上。

　　但是，如果你以數(shù)據(jù)庫數(shù)據(jù)替代狀態(tài)，那么就可能導(dǎo)致數(shù)據(jù)庫的頻繁訪問，而且 你的系統(tǒng)會變成一個非對象化的、緊耦合、到處是分散數(shù)據(jù)塊的糟糕系統(tǒng)。這樣的系統(tǒng)并不比傳統(tǒng)的兩層結(jié)構(gòu)好到哪里！也不會比Jsp里嵌入Java代碼偽三層系統(tǒng)高明到什么地方。

什么是狀態(tài)？

　　只要有對象就可能有狀態(tài)，任何一個對象活動時，都有自己的狀態(tài)屬性，類的 字段屬性極有可能成為狀態(tài)，我們現(xiàn)在經(jīng)常使用的Domain model其實就是一種 包含狀態(tài)的對象，如果你對狀態(tài)沒有深入掌握，就不可能真正掌握對象系統(tǒng)特點，或者是Domain Model的執(zhí)行情況。

　　對于初學(xué)者，經(jīng)常會疑問：我是將數(shù)據(jù)放在HttpSession中還是Request中，這里 其實已經(jīng)開始接觸狀態(tài)，一旦你接觸狀態(tài)，你就要開始小心，因為你可能會將內(nèi)存泄漏的惡魔導(dǎo)引進(jìn)來。

　　內(nèi)存泄漏的惡魔爆發(fā)時刻取決于你狀態(tài)的生存周期和系統(tǒng)并發(fā)訪問量。

　　狀態(tài)的生存周期也就是包含這個狀態(tài)的對象的生命周期，在簡單系統(tǒng)中，我們只 需要通過new創(chuàng)建對象，然后它的消亡就會依靠JVM垃圾回收機制回收，但是事情會這么簡單嗎？

　　狀態(tài)的危險還會發(fā)生在多線程環(huán)境下，當(dāng)多個線程對同一個內(nèi)存中狀態(tài)寫操作時，這時怎么辦？如果這個狀 態(tài)持久化在數(shù)據(jù)庫中，我們會依賴數(shù)據(jù)庫提供的強大事務(wù)機制防止這種并發(fā)死鎖，但是如果是在內(nèi)存中，你就很難辦，因此，我們就盡量避免發(fā)生這種多線程同時訪 問一個狀態(tài)的現(xiàn)象，而Singleton單例模式極容易發(fā)生這種現(xiàn)象，因此實踐中，單例模式是J2EE開發(fā)中需要避免的，相關(guān)帖子討論見：
http://www.jdon.com/jive/article.jsp?forum=91&thread=17578

　　我們接觸的Web容器或Jsp/Servlet本質(zhì)就是一個多線程，這也是很多初學(xué)者不知道的， 因為多線程編程是復(fù)雜或困難的，因此才有jsp/Servlet這樣的上層封裝，但是我們使用他們
時，實際在進(jìn)行多線程編程。

　　生命周期和多線程并發(fā)使得我們簡單的面向?qū)ο笙到y(tǒng)變得異常復(fù)雜和難以掌握起來。下面我從這個兩個角度，給出兩種模式思維解決之道。

生命周期(Scope)

　　生命周期(Scope)就是指狀態(tài)的活動周期，狀態(tài)對象是什么時候被創(chuàng)建；然后什么時候被銷毀，很顯然，如果狀態(tài)對象還沒有被創(chuàng)建或已經(jīng)被銷毀，你再 訪問這個狀態(tài)對象可能失敗，而狀態(tài)的生命周期控制是可能散落在運行程序的各個地方，如果不象狀態(tài)模式那樣進(jìn)行統(tǒng)一控制，有可能整個系統(tǒng)是危機四伏的。

　　狀態(tài)的生命周期其實就是對象生命周期，更加細(xì)化地說：是Domain Model這個對象的生命周期。這在一個以領(lǐng)域模型為驅(qū)動的設(shè)計概念中不可回避的課題，而領(lǐng)域模型實戰(zhàn)的復(fù)雜性就復(fù)雜在此。

　　狀態(tài)的生命周期在J2EE中目前有三種：Request/Session和 Application，Request是每個客戶端發(fā)出的一次請求，這是J2EE系統(tǒng)中最基本的事件激活單元， 當(dāng)服務(wù)器端推出一個頁面到客戶端時，意味著這個Request的結(jié)束。那么如果我們的狀態(tài)保存在Request中，意味著在request結(jié)束之前，這個 請求經(jīng)歷的任何一個環(huán)節(jié)都可以對這個狀態(tài)（對象）進(jìn)行操作。（掌握這個原理，對于你學(xué)習(xí)Struts和JSF很有幫助）

　　如果是Session，則一直和該客戶端有關(guān)，只要是該客戶端發(fā)出的每次request的任何環(huán)節(jié)都可以對這個狀態(tài)（對象）進(jìn)行操作。

　　如果是Application，則意味著這個狀態(tài)是當(dāng)前Web項目的全局狀態(tài)。

　　這三種狀態(tài)形式都是以將狀態(tài)保存在內(nèi)存中形式存在的，是和持久化狀態(tài)相對的。是一種內(nèi)存活動狀態(tài)。

　　生命周期的選取當(dāng)然是越短越好，這樣，這個狀態(tài)對象就可以被自動銷毀，從而避免了
大訪問量下的內(nèi)存泄漏，但是在大訪問量下，對象頻繁創(chuàng)建和銷毀是耗費性能的。

　　那么，我們可能經(jīng)常使用HttpSession來保存狀態(tài)，這時你極有可能造成內(nèi)存泄漏，我經(jīng)常在 Jdon論壇上看到將很多數(shù)據(jù)庫數(shù)據(jù)暫時保存在HttpSession中想法，這是相當(dāng)危險的，因為一旦并發(fā)用戶很多，相當(dāng)多的HttpSession包 含了狀態(tài)，而狀態(tài)中有可能有更多其他引用，因此內(nèi)存很快會爆滿，或者垃圾回收機制頻繁啟動，造成應(yīng)用系統(tǒng)運行暫停或緩慢。

　　當(dāng)你將狀態(tài)放入HttpSession時，難道沒有考慮將其手工消除嗎？你要知道所有Web容器 （Tomcat/Weblogic等）都不會自動替你清除那些你可能不用的狀態(tài)對象啊。如果每個人只管新增元素，不管重整或管理，這個系統(tǒng)能不變得混亂 嗎？代碼上這種現(xiàn)象我們是通過Refactoring等結(jié)構(gòu)/行為模式來解決，那么在運行時的狀態(tài)管理呢？

　　狀態(tài)管理模式或者說對象管理模式正是解決這種問題的。

　　 按照該模式，你必須手工自己管理放在HttpSession的狀態(tài)，比如你為每個HttpSession
設(shè)立一個狀態(tài)容器最大尺寸，當(dāng)超過這個尺寸時，你需要將不用的狀態(tài)從容器去除， 但是如果這個客戶端在Session失效期內(nèi)又來訪問這個狀態(tài)怎么辦？那么你可能需要先臨時將狀態(tài)序列化保存到硬盤上，等Session失效期到達(dá)后再真正刪除。

　　是不是覺得很麻煩？
　　捷徑是有：
　　1. 盡量少使用HttpSession保存狀態(tài)，這對集群環(huán)境也是有利的，見該貼討論：
http://www.jdon.com/jive/article.jsp?forum=121&thread=22282
那么這些狀態(tài)放在哪里？使用Application的緩存中，

　　2. 使用狀態(tài)管理中間件，目前有幾個選擇：EJB的有態(tài)Bean；NanoContainer之類狀態(tài)相關(guān)的微容器。那么Spring可以嗎？目前沒有發(fā)現(xiàn)有 該功能，甚至在Spring容器內(nèi)無法直接使用Session性質(zhì)的狀態(tài)，只能通過線程級別的ThreadLocal來實現(xiàn)(對不起，你又要開始回到遠(yuǎn)古 的匯編線程時代了)；而Jdon框架則可以。

　　下面我們談?wù)凙pplication的狀態(tài)，在這個范圍內(nèi)，一個對象狀態(tài)可以被多個用戶反復(fù)訪問，在這個級別，狀態(tài)類似數(shù)據(jù)庫中數(shù)據(jù)，因為可以使用數(shù)據(jù)庫來替代這個級別的狀態(tài)，所以將狀態(tài)放入緩存這個深層次技術(shù)被大多數(shù)初學(xué)者忽視了，甚至產(chǎn)生了對數(shù)據(jù)庫依賴心理。

緩存中的狀態(tài)

　　雖然我們將狀態(tài)保存在Application中，但是我們不可避免還是遇到Session同樣的狀態(tài)管理問題，這個問題所幸的是有專門緩存中間件解決 了，當(dāng)然，在一個多服務(wù)器集群系統(tǒng)，如果一個客戶端在一個服務(wù)器中存放了狀態(tài)，那么能否在另外一個服務(wù)器的內(nèi)存中訪問到呢？回答是肯定的，前提是你必須使 用分布式緩存系統(tǒng)。

　　目前分布式緩存系統(tǒng)是靠EJB服務(wù)器完成，當(dāng)JBoss 5在2006變成完全解耦、可肢解時，
我們就可以使用原本只支持EJB的JBoss分布式緩存系統(tǒng)來支持我們的普通JavaBeans了(POJO)。這其中目前可能會花費一些力氣，因為還沒有一個統(tǒng)一的POJO構(gòu)件接口標(biāo)準(zhǔn)，我相信以后
可能會有。

　　如果你不想花費力氣，而且可能就只是一臺服務(wù)器，可以通過雙核芯片提升性能，那么單態(tài)緩存如果實現(xiàn)？很簡單，使用一個緩存產(chǎn)品如OsCache等，將其設(shè)定保存在 Application中，或者在web.xml中進(jìn)行一下簡單的配置即可。

　　但是，這時你可能碰到另外一個問題：狀態(tài)的唯一標(biāo)識，如何通過唯一標(biāo)識從緩存中那么
多對象狀態(tài)中取出你要的那一個呢？比較瑣碎。

　　有沒有一個框架幫助你省卻這些麻煩，當(dāng)然推薦Jdon Framework，只要將包含狀態(tài)的類（主要是Domain Model）繼承特定的類或接口（接口在1.4版本實現(xiàn)）即可，這個類的對象運行時就會被緩存或從緩存中讀取，再也無需你照料緩存了，就這么簡單。

　　當(dāng)然，Jdon Framework的底層緩存器是可以被替代，使用你喜歡的緩存產(chǎn)品，因為jdon
Framework是基于Ioc設(shè)計，構(gòu)件之間是完全解耦、可徹底肢解，能夠通過配置替代和更換的。
如果你不明白這個道理，需要好好研究一下Ioc模式帶給我們革命性的新變化。

　　從以上也可以看出：java復(fù)雜性還在于我們需要在編碼時，卻要想象其運行時的情形。而這種翻譯聯(lián)想沒有深厚的實踐功底，是很難順利完成的。

狀態(tài)管理中間件

　　自從J2EE開辟中間件時代以來，就有相當(dāng)多的高級中間件提供與具體應(yīng)用無關(guān)的通用功能，狀態(tài)管理中間件很早就有之，EJB的有態(tài)Session Bean是一個代表。

　　一個中間件不但要有良好的松耦合設(shè)計，我們暫時稱為靜態(tài)設(shè)計；更要有優(yōu)秀的動態(tài)設(shè)計，例如狀態(tài)管理就屬于一種動態(tài)設(shè)計。

　　當(dāng)然，如果你比較謙虛，不但要選擇一些靜態(tài)設(shè)計很好的框架或中間件；而且還要依賴一些擁有良好的動態(tài)運行管理的中間件。

　　EJB無論是EJB1.X/EJB2.X/EJB3.X.在狀態(tài)管理上要更加優(yōu)秀，當(dāng)然EJB3.X又吸收了優(yōu)秀的靜態(tài)設(shè)計概念，但是因為需要有一個具體服務(wù)器實現(xiàn)過程，這個過程中存在一些陷阱，如In-Box問題等。

　　Spring無疑是一個靜態(tài)設(shè)計非常優(yōu)秀框架，它一直在AOP上孜孜不倦，力圖探索一條從AOP角度進(jìn)行動態(tài)運行管理干預(yù)捷徑，相信會有驚人結(jié)果，當(dāng)然，這種細(xì)粒度的AOP需要實踐檢驗，當(dāng)然如果整入JDK 6.0就更好。

　　而Jdon Framework則試圖在目前兩者之間尋求了一個平衡，既有Ioc/AOP優(yōu)秀的靜態(tài)設(shè)計，雖然在AOP上不及Spring前衛(wèi)；但提供了切實Session和Cache狀態(tài)管理；

　　如果你不需要EJB的分布式多服務(wù)器集群功能；又不是AOP的超級粉絲，無疑使用Jdon Framework之類的框架無疑是簡化方便的。

狀態(tài)設(shè)計的難點

　　最后，我不得不重申，并不是有了良好的狀態(tài)管理框架就可以高枕無憂了，狀態(tài)的設(shè)計其實是我們每個項目必須面臨的可變課題，如果狀態(tài)復(fù)雜了可以使用狀態(tài)模式對付，可惜往往狀態(tài)不夠復(fù)雜。

　　一個對象本身屬性和狀態(tài)是應(yīng)該耦合在一起，還是進(jìn)行分離，屬性和狀態(tài)沒有明顯的涇渭分明的界限，我們舉一個例子：

　　論壇Forum這個對象，它有一些字段屬性，如論壇名稱、論壇描述，還有其他一些相關(guān)屬性：如該論壇 的最新發(fā)帖；該論壇的發(fā)貼量，后兩者好像也是論壇字段，但是他們可能經(jīng)常變化的，應(yīng)該屬于狀態(tài)，那么狀態(tài)和Forum這個主體對象是什么關(guān)系？是將該論壇 的最新發(fā)帖和該論壇的發(fā)貼量兩個字段并入Forum這個Domain Model中，還是應(yīng)該單獨建立一個狀態(tài)對象？如果進(jìn)行分離，分離的依據(jù)是什么？

　　當(dāng)然，這里分離的依據(jù)是因為對象的生存周期不同。對于我們熟悉的課題，我們能夠馬上分辨出其中的生存周期，如果是不熟悉領(lǐng)域的建模呢？

　　所以，大家已經(jīng)明白：狀態(tài)設(shè)計的難點是：如何粒度細(xì)化地創(chuàng)建模型對象；然后分辨出其中動態(tài)的狀態(tài)性質(zhì)。這是域建模實戰(zhàn)中一個難點。

　　很多人問我：你提倡的域建模、設(shè)計模式和框架是什么意思？為什么說他們是Java開發(fā)設(shè)計的三件寶呢？或者說三個典型知識點呢？我想通過本篇我已經(jīng)通過狀態(tài)這個概念稍微解釋了域建模的一些特點。

　　當(dāng)前，MDA中的四色原型模式Archetype將幫助我們更好地分辨出類的屬性、狀態(tài)和行為，這是一場帶來以后十年的軟件革命，

(1) 訪問流程:

(1.1) 系統(tǒng)運行在某web容器,如Tomcat(其運行和weblogic不同,Tomcat只有一個進(jìn)程).

      其預(yù)設(shè)有初始的線程數(shù).

(1.2) 瀏覽器打開某網(wǎng)站,網(wǎng)站及給其分配一個sessionID(頁面隱式的發(fā)起request, 由Tomcat

      某個特定的監(jiān)聽線程給予response一個sessionid). 該sessionid用以識別本次訪問.

(1.3) 用戶點擊登錄/注冊, 瀏覽器發(fā)起一個新的request, 由Tomcat線程池中空閑的線程進(jìn)行

       處理. 反饋結(jié)果于前臺展現(xiàn).如線程池中線程不足,則Tomcat每次按照一定規(guī)則創(chuàng)建出更多的空閑線程(其初始值,增加值,及最大值依據(jù)配置文件/JDK/硬件).

最近在做登錄和權(quán)限控制模塊，用到了session，發(fā)現(xiàn)session的好多方法都不熟悉，而且以前也聽說過JsessionId 之類session竊取的事，

對這些一直都是一知半解。今天索性google了很多資料，先上sun的官網(wǎng)去看session的文檔了解一些方法，又找了別人關(guān)于session的看法。

總結(jié)如下：

      1，session是什么？  what

          session經(jīng)常譯為會話，以打電話為例，從開始撥號到掛斷電話就是你會話的生存周期。

      2，session 做什么用的  why？

          首先舉個例子：

                咖啡店舉行 消費滿5杯咖啡贈送一杯的活動，可每個人一次消費5杯的時候非常少。這時候有3種辦法：

                1，店員看到每個顧客時都能記住其消費了多少杯，從而給其優(yōu)惠，這是協(xié)議本身具有狀態(tài)

                2，給每個顧客一個卡片，上面記錄顧客的每次消費，這是客戶端保存狀態(tài)

                3，給每個顧客一個卡片，卡片上只有一個編號，顧客每次的消費記錄在店里，這就是 服務(wù)端有狀態(tài)

          而http本身是無狀態(tài)的，所以我們只能使用2，3中方法，來保存一些信息。

          實際采用的是第3種方法，服務(wù)器段保存一次會話所有的信息，并生成一個唯一的id，這個id沒有規(guī)律而且不會重復(fù)，將這個id傳回到客戶段，

保存到cookie中。每次訪問服務(wù)器時，客戶端都會偷偷將這個id傳到服務(wù)器，服務(wù)器根據(jù)id查到這次會話保存的內(nèi)容。就能實現(xiàn)會話中共享一些數(shù)據(jù)。

     3，session怎樣創(chuàng)建和銷毀 ？ how

         session是保存在內(nèi)存中的，所以會有一些性能上的影響。因此本著這個原則，session是只有在使用到的時候才會被創(chuàng)建，如果始終沒有用到

session，這個session是永遠(yuǎn)不會被創(chuàng)建的。

        比如： 訪問servlet ，只要你代碼中沒有 request.getSession()或request.getSession(true);這兩行是等價的，那session是不會創(chuàng)建。

又 當(dāng)你訪問靜態(tài)頁面時，根本不會生成servlet，所以也不會創(chuàng)建session。

       下面解釋一些疑惑： session是第一次請求時創(chuàng)建的？

  大家都知道 jsp是被編譯成servlet才執(zhí)行的，問題就在jsp編譯的過程。

 jsp中有個<%@ page session="true/false"%> 這個開關(guān)表示是否創(chuàng)建session，當(dāng)你不寫這行時，它會默認(rèn)給你加上這句。所以會造成上面的疑惑。

當(dāng)然還有一些標(biāo)簽中可能有g(shù)etSession()操作，會產(chǎn)生一些不必要的session。

       session只能在服務(wù)端銷毀，有三種途徑： 1，到達(dá)session的最大請求間隔時間時，2，session。invalidate()

 3,服務(wù)器進(jìn)程當(dāng)?shù)簟?/p>

       這里也有一些疑惑： 瀏覽器關(guān)閉時，session就會注銷。

       首先瀏覽器關(guān)閉時，瀏覽器并沒有給服務(wù)器發(fā)送任何消息，所以服務(wù)器不會知道瀏覽器何時關(guān)閉了。

 上面我們知道取得session 是因為瀏覽器cookie中有sessionid，而普通cookie通常會是會話cookie，也就是說瀏覽器關(guān)閉時，這個cookie會被注銷，

所以當(dāng)你再訪問服務(wù)器時就沒有sessionid了，所以造成session關(guān)閉了的假象，如果昵稱通過特殊方法將sessionid傳遞給服務(wù)器，你會發(fā)現(xiàn)session還在。

如果想讓cookie保存時間長一些，就需要手動指定cookie的過期時間

 

4，實際項目中的難點：

     1，瀏覽器禁用cookie

      這就沒辦法保存sessionid了，可以采用url重寫，轉(zhuǎn)發(fā)，加隱藏字段等方法來將sessionid傳給服務(wù)器。

     如：  baidu.com:jsessionid=adfasdfasdfasdfasdfafdadf?asdfasdf

             baidu.com?jsessionid=asdfasdfasdfadsfad&&adfdf

 這根據(jù)服務(wù)器的不同實現(xiàn)，第一種可以將普通參數(shù)區(qū)分開。

 

     2，多人共用session的問題

        例： a 訪問 baidu.com ,但他沒有帳號，于是他將連接 baidu.com/login.jsp?jsessionid=adsfasdfad（這個a的sessionid） 發(fā)給B, B登錄

后，a就相當(dāng)于用b的帳號登錄了。你們可以在在本地試試。

        解決方法： 當(dāng)發(fā)現(xiàn)通過sessionid從url指定時， 創(chuàng)建一個新的session，將舊session的信息復(fù)制到 新sessoin中，然后將新session注銷。

就能防止上面那種情況了。

    3，一個帳號多地方登錄

       比如： 你用abc帳號登錄了baidu.com,有打開了一個瀏覽器，又用abc帳號登錄了一次。當(dāng)不設(shè)計敏感操作時，這無所謂，而當(dāng)你做一些敏感操

作時就必須禁止這樣情況，防止同時操作，造成重復(fù)操作，或者數(shù)據(jù)損壞。

     解決方法： 監(jiān)聽session，將username和sessionid對應(yīng)起來，當(dāng)username再次登錄時，注銷掉以前的session，保存現(xiàn)在的session，這也是

一種比較不錯的方案。

 

 

http://www.iteye.com/topic/257191

今天下午研究了半天hashcode()和equals()方法，終于有了一點點的明白，寫下來與大家分享（zhaoxudong 2008.10.23晚21.36）。
1. 首先equals()和hashcode()這兩個方法都是從object類中繼承過來的。
equals()方法在object類中定義如下：
  public boolean equals(Object obj) {
return (this == obj);
}
很明顯是對兩個對象的地址值進(jìn)行的比較（即比較引用是否相同）。但是我們必需清楚，當(dāng)String 、Math、還有Integer、Double。。。。等這些封裝類在使用equals()方法時，已經(jīng)覆蓋了object類的equals（）方法。比 如在String類中如下：
  public boolean equals(Object anObject) {
if (this == anObject) {
    return true;
}
if (anObject instanceof String) {
    String anotherString = (String)anObject;
    int n = count;
    if (n == anotherString.count) {
char v1[] = value;
char v2[] = anotherString.value;
int i = offset;
int j = anotherString.offset;
while (n-- != 0) {
    if (v1[i++] != v2[j++])
return false;
}
return true;
    }
}
return false;
}
很明顯，這是進(jìn)行的內(nèi)容比較，而已經(jīng)不再是地址的比較。依次類推Double、Integer、Math。。。。等等這些類都是重寫了equals()方法的，從而進(jìn)行的是內(nèi)容的比較。當(dāng)然了基本類型是進(jìn)行值的比較，這個沒有什么好說的。
我們還應(yīng)該注意，Java語言對equals()的要求如下，這些要求是必須遵循的：
• 對稱性：如果x.equals(y)返回是“true”，那么y.equals(x)也應(yīng)該返回是“true”。
• 反射性：x.equals(x)必須返回是“true”。
• 類推性：如果x.equals(y)返回是“true”，而且y.equals(z)返回是“true”，那么z.equals(x)也應(yīng)該返回是“true”。
• 還有一致性：如果x.equals(y)返回是“true”，只要x和y內(nèi)容一直不變，不管你重復(fù)x.equals(y)多少次，返回都是“true”。
• 任何情況下，x.equals(null)，永遠(yuǎn)返回是“false”；x.equals(和x不同類型的對象)永遠(yuǎn)返回是“false”。
以上這五點是重寫equals()方法時，必須遵守的準(zhǔn)則，如果違反會出現(xiàn)意想不到的結(jié)果，請大家一定要遵守。
2. 其次是hashcode() 方法，在object類中定義如下：
  public native int hashCode();
說明是一個本地方法，它的實現(xiàn)是根據(jù)本地機器相關(guān)的。當(dāng)然我們可以在自己寫的類中覆蓋hashcode()方法，比如String、 Integer、Double。。。。等等這些類都是覆蓋了hashcode()方法的。例如在String類中定義的hashcode()方法如下：
    public int hashCode() {
int h = hash;
if (h == 0) {
    int off = offset;
    char val[] = value;
    int len = count;

            for (int i = 0; i < len; i++) {
                h = 31*h + val[off++];
            }
            hash = h;
        }
        return h;
}
解釋一下這個程序（String的API中寫到）：
s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]
使用 int 算法，這里 s[i] 是字符串的第 i 個字符，n 是字符串的長度，^ 表示求冪。（空字符串的哈希碼為 0。）

3.這里我們首先要明白一個問題：
equals()相等的兩個對象，hashcode()一定相等；
equals（）不相等的兩個對象，卻并不能證明他們的hashcode()不相等。換句話說，equals()方法不相等的兩個對象，hashcode()有可能相等。（我的理解是由于哈希碼在生成的時候產(chǎn)生沖突造成的）。
反過來：hashcode()不等，一定能推出equals()也不等；hashcode()相等，equals()可能相等，也可能不等。解釋 下第3點的使用范圍，我的理解是在object、String等類中都能使用。在object類中，hashcode()方法是本地方法，返回的是對象的 地址值，而object類中的equals()方法比較的也是兩個對象的地址值，如果equals()相等，說明兩個對象地址值也相等，當(dāng)然 hashcode()也就相等了；在String類中，equals()返回的是兩個對象內(nèi)容的比較，當(dāng)兩個對象內(nèi)容相等時，
Hashcode()方法根據(jù)String類的重寫（第2點里面已經(jīng)分析了）代碼的分析，也可知道hashcode()返回結(jié)果也會相等。以此類 推，可以知道Integer、Double等封裝類中經(jīng)過重寫的equals()和hashcode()方法也同樣適合于這個原則。當(dāng)然沒有經(jīng)過重寫的 類，在繼承了object類的equals()和hashcode()方法后，也會遵守這個原則。

4.談到hashcode()和equals()就不能不說到hashset,hashmap,hashtable中的使用，具體是怎樣呢，請看如下分析：
Hashset是繼承Set接口，Set接口又實現(xiàn)Collection接口，這是層次關(guān)系。那么hashset是根據(jù)什么原理來存取對象的呢？
在hashset中不允許出現(xiàn)重復(fù)對象，元素的位置也是不確定的。在hashset中又是怎樣判定元素是否重復(fù)的呢？這就是問題的關(guān)鍵所在，經(jīng)過一下午的查詢求證終于獲得了一點啟示，和大家分享一下，在java的集合中，判斷兩個對象是否相等的規(guī)則是：
1)，判斷兩個對象的hashCode是否相等
      如果不相等，認(rèn)為兩個對象也不相等，完畢
      如果相等，轉(zhuǎn)入2)
（這一點只是為了提高存儲效率而要求的，其實理論上沒有也可以，但如果沒有，實際使用時效率會大大降低，所以我們這里將其做為必需的。后面會重點講到這個問題。）
2)，判斷兩個對象用equals運算是否相等
      如果不相等，認(rèn)為兩個對象也不相等
      如果相等，認(rèn)為兩個對象相等（equals()是判斷兩個對象是否相等的關(guān)鍵）
為什么是兩條準(zhǔn)則，難道用第一條不行嗎？不行，因為前面已經(jīng)說了，hashcode()相等時，equals()方法也可能不等，所以必須用第2條準(zhǔn)則進(jìn)行限制，才能保證加入的為非重復(fù)元素。
比如下面的代碼：

public static void main(String args[]){
String s1=new String("zhaoxudong");
String s2=new String("zhaoxudong");
System.out.println(s1==s2);//false
System.out.println(s1.equals(s2));//true
System.out.println(s1.hashCode());//s1.hashcode()等于s2.hashcode()
System.out.println(s2.hashCode());
Set hashset=new HashSet();
hashset.add(s1);
hashset.add(s2);
/*實質(zhì)上在添加s1,s2時，運用上面說到的兩點準(zhǔn)則，可以知道hashset認(rèn)為s1和s2是相等的，是在添加重復(fù)元素，所以讓s2覆蓋了s1;*/
Iterator it=hashset.iterator();
            while(it.hasNext())
            {
             System.out.println(it.next());
            }
最后在while循環(huán)的時候只打印出了一個”zhaoxudong”。
輸出結(jié)果為：false
            true
            -967303459
            -967303459
這是因為String類已經(jīng)重寫了equals()方法和hashcode()方法，所以在根據(jù)上面的第1.2條原則判定時，hashset認(rèn)為它們是相等的對象，進(jìn)行了重復(fù)添加。
但是看下面的程序：
import java.util.*;
public class HashSetTest
{
   public static void main(String[] args)
    {
                 HashSet hs=new HashSet();
                 hs.add(new Student(1,"zhangsan"));
                 hs.add(new Student(2,"lisi"));
                 hs.add(new Student(3,"wangwu"));
                 hs.add(new Student(1,"zhangsan"));
 
                 Iterator it=hs.iterator();
                 while(it.hasNext())
                 {
                        System.out.println(it.next());
                 }
     }
}
class Student
   {
     int num;
     String name;
     Student(int num,String name)
                {
                this.num=num;
                 this.name=name;
                 }
              public String toString()
                {
                    return num+":"+name;
                 }
           }     
輸出結(jié)果為：
                      1:zhangsan
                   1:zhangsan
                   3:wangwu
                   2:lisi
問題出現(xiàn)了，為什么hashset添加了相等的元素呢，這是不是和hashset的原則違背了呢？回答是：沒有
因為在根據(jù)hashcode()對兩次建立的new Student(1,"zhangsan")對象進(jìn)行比較時，生成的是不同的哈希碼值，所以hashset把他當(dāng)作不同的對象對待了，當(dāng)然此時的 equals()方法返回的值也不等（這個不用解釋了吧）。那么為什么會生成不同的哈希碼值呢？上面我們在比較s1和s2的時候不是生成了同樣的哈希碼 嗎？原因就在于我們自己寫的Student類并沒有重新自己的hashcode()和equals()方法，所以在比較時，是繼承的object類中的 hashcode()方法，呵呵，各位還記得object類中的hashcode()方法比較的是什么吧！！
它是一個本地方法，比較的是對象的地址（引用地址），使用new方法創(chuàng)建對象，兩次生成的當(dāng)然是不同的對象了（這個大家都能理解吧。。。），造成 的結(jié)果就是兩個對象的hashcode()返回的值不一樣。所以根據(jù)第一個準(zhǔn)則，hashset會把它們當(dāng)作不同的對象對待，自然也用不著第二個準(zhǔn)則進(jìn)行 判定了。那么怎么解決這個問題呢？？
答案是：在Student類中重新hashcode()和equals()方法。
例如：
  class Student
{
int num;
String name;
Student(int num,String name)
{
            this.num=num;
            this.name=name;
}
public int hashCode()
{
            return num*name.hashCode();
}
public boolean equals(Object o)
{
            Student s=(Student)o;
            return num==s.num && name.equals(s.name);
}
public String toString()
{
            return num+":"+name;
}
}
根據(jù)重寫的方法，即便兩次調(diào)用了new Student(1,"zhangsan")，我們在獲得對象的哈希碼時，根據(jù)重寫的方法hashcode()，獲得的哈希碼肯定是一樣的（這一點應(yīng)該沒有疑問吧）。
當(dāng)然根據(jù)equals()方法我們也可判斷是相同的。所以在向hashset集合中添加時把它們當(dāng)作重復(fù)元素看待了。所以運行修改后的程序時，我們會發(fā)現(xiàn)運行結(jié)果是：
                      1:zhangsan
                   3:wangwu
                   2:lisi
可以看到重復(fù)元素的問題已經(jīng)消除。
關(guān)于在hibernate的pojo類中，重新equals()和hashcode()的問題：
1)，重點是equals，重寫hashCode只是技術(shù)要求（為了提高效率）
2)，為什么要重寫equals呢，因為在java的集合框架中，是通過equals來判斷兩個對象是否相等的
3)，在hibernate中，經(jīng)常使用set集合來保存相關(guān)對象，而set集合是不允許重復(fù)的。我們再來談?wù)勄懊嫣岬皆谙騢ashset集合中添加元素時,怎樣判斷對象是否相同的準(zhǔn)則，前面說了兩條，其實只要重寫equals()這一條也可以。
但當(dāng)hashset中元素比較多時，或者是重寫的equals()方法比較復(fù)雜時，我們只用equals()方法進(jìn)行比較判斷，效率也會非常低， 所以引入了hashcode()這個方法，只是為了提高效率，但是我覺得這是非常有必要的（所以我們在前面以兩條準(zhǔn)則來進(jìn)行hashset的元素是否重復(fù) 的判斷）。
比如可以這樣寫：
public int hashCode(){
   return  1;}//等價于hashcode無效
這樣做的效果就是在比較哈希碼的時候不能進(jìn)行判斷，因為每個對象返回的哈希碼都是1，每次都必須要經(jīng)過比較equals()方法后才能進(jìn)行判斷是否重復(fù)，這當(dāng)然會引起效率的大大降低。
我有一個問題，如果像前面提到的在hashset中判斷元素是否重復(fù)的必要方法是equals()方法（根據(jù)網(wǎng)上找到的觀點），但是這里并沒有涉及到關(guān)于哈希表的問題，可是這個集合卻叫hashset，這是為什么？？
我想，在hashmap,hashtable中的存儲操作，依然遵守上面的準(zhǔn)則。所以這里不再多說。這些是今天看書，網(wǎng)上查詢資料，自己總結(jié)出來 的，部分代碼和語言是引述，但是千真萬確是自己總結(jié)出來的。有錯誤之處和不詳細(xì)不清楚的地方還請大家指出，我也是初學(xué)者，所以難免會有錯誤的地方，希望大 家共同討論。