首先談一下對session對象在web開發中的創建以及sessionId生成并返回客戶端的運行機制.
session對象當客戶端首次訪問時,創建一個新的session對象.并同時生成一個sessionId,并在此次響應中將sessionId以響應報文的方式些回客戶端瀏覽器內存或以重寫url方式送回客戶端,來保持整個會話,只要sever端的這個session對象沒有銷毀,以后再調用request.getSession() 時就直接根據客戶端的sessionId來檢索server端生成的session對象并返回,不會再次去新建,除非根據此sessionId沒有檢索到 session對象.
下面是在IE下測試,因為IE6.0的一個BUG就是IE的隱私設置即使是阻止所有cookie時,也還是會以會話cookie來保存sessionId.所以下面都是以會話cookie來討論的,
(1)在server沒有關閉,并在session對象銷毀時間內,當客戶端再次來請求server端的servlet或jsp時, 將會將在第一次請求時生成的sessionId并附帶在請求信息頭中并向server端發送,server端收到sessionId后根據此 sessionId會去搜索(此過程是透明的)server對應的session對象并直接返回這個session對象,此時不會重新去建立一個新的 session對象.
(2)當server關閉(之前產生的session對象也就消亡了),或session對象過了其銷毀時間后, 瀏覽器窗口不關,并在本瀏覽器窗口再次去請求sever端的servlet和jsp時,此時同樣會將sessionId(server關閉或 session銷毀時生成的sessionId)發送到server端,server根據sessionId去找其對應的session對象,但此時 session對象已經不存在,此時會重新生成一個新的session對象,并生成新的sessionId并同樣將這個新生成的sessionId以響應報文的形式送到瀏覽器內存中.
(3)當server沒有關閉,并session對象在其銷毀時間內,當請求一個jsp頁面回客戶端后, 關閉此瀏覽器窗口,此時其內存中的sessionId也就隨之銷毀,在重新去請求sever端的servlet或jsp時,會重新生成一個 sessionId給客戶端瀏覽器,并存在瀏覽內存中.
上面的理論在servlet中測試都是成立的,下面談一下在struts框架下進行上面的測試時的不同的地方.
先簡要說下測試程序的流程:
客戶端請求index.do--->進入server端的IndexAction--->轉向login.jsp頁面----->請求login.do----->進入server端的LoginAction.
首先說明:IndexAction中沒有去產生session對象,login.jsp中設置.
(1)環境servlet + jsp:
在sevlet+jsp測試跟蹤時,在index.do進入IndexAction后轉向login.jsp時,此時瀏覽器內存中是沒有會話cookie的,那么在login.jsp上請求login.do進入LoginAction后,用request.getCookies()測試時,其值是為null的!結果是穩合的,因為從始置終沒有產生過session嘛!
(2)環境struts + jsp:
在struts+jsp測試跟蹤時,跟上面的流程一樣,開始想結果也應該是一樣的,但經過調試后發現結果卻不是所想的那樣.在login.do進入 LoginActoin后用,用request.getCookies()測試時,發現其值不為null,即其有name和value,開始很不理解,因為根本就沒有創建過session對象,哪來的會話cookie值呢.但是結果有,那么想著此時瀏覽器內存中也就應該有會話cookie,問題就在這里! 從哪里來的?
后來經過仔細考慮后,想到struts中的特點,我們自己寫的Action類是繼承struts的Action的,而且之前是經過struts的中央控制器ActionServlet來控制轉向的,所以我想肯定是在程序進入我自己寫的IndexAction之前, struts框架中的代碼肯定已經創建了session對象并已經生成了sessionId.于是就找到相關書籍查看了ActionServlet工作流程以及調用哪些類,看了之后果然在其中看到了HttpSession session = request.getSession();這樣一句話!于是答案也就明了了.
大家知道struts的ActionServlet類中在接收到我們客戶端的請求(*.do)后(之前會做一系列初始化工作),并不是直接去處理我們的請求并調用相應的Action(我們寫的如 IndexAction),而是將處理工作交給RequestProcessor類,其process方法中會調用一系列的方法來完成相應的請求處理和轉向操作.其中有一個方法引起了我的關注,就是processLocale()方法.
Struts框架:RequestProcess類中的processLocale()方法原型如下:
程序代碼:
protected void processLocale(HttpServletRequest request,
HttpServletResponse response) {
// Are we configured to select the Locale automatically?
if (!moduleConfig.getControllerConfig().getLocale()) {
return;
}
// Has a Locale already been selected?
HttpSession session = request.getSession();
if (session.getAttribute(Globals.LOCALE_KEY) != null) {
return;
}
// Use the Locale returned by the servlet container (if any)
Locale locale = request.getLocale();
if (locale != null) {
if (log.isDebugEnabled()) {
log.debug(" Setting user locale '" + locale + "'");
}
session.setAttribute(Globals.LOCALE_KEY, locale);
}
}
此類在struts-config.xml配置文件中有對應的配置項: < controller locale="true">< /controller> 其缺省狀態locale屬性的值為true,也就會調用processLocale方法,并在第一次請求時創建session對象和生成 sessionId.但改為false后,在第一次請求到達ActionServlet后不會調用processLocale方法,也就不會生成 session對象了。
結果也就出來了，在struts應用中,*.do到達server端后經過ActionServlet后轉想我們自己寫的IndexAction之前, < controller locale="true">< /controller>(缺省狀態) 時,就已經產生了session對象和sessionId,這是struts框架類中生成的,即使我們在IndexAction中寫上 HttpSession session = request.getSession();其也是RequestProcess類中的processLocale()方法生成的,此時其session 的isNew也還是true,因為還沒有返回客戶端,其是新創建的,那么按照上面的流程,當在login.jsp上通過login.do進入 LoginAction后,其request.getCookies()固然也就有值了!并且其值是RequestProcess類中的 processLocale()方法產生session對象時生成的.
如果我們在struts-config.xml中加上< controller locale="false">< /controller> 時,此時如果再根據上面的流程來跟蹤程序,并在LoginAction用request.getCookies()測試時,其值是為null的,當然在 IndexAction寫上HttpSession session = request.getSession();時其是進入IndexAction時新創建的,isNew也是true。
察看了JBOSS的源代碼，命名服務器拋出的這個異常分析如下
java.net.SocketException: Software caused connection abort: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1639)
at java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1548)
at java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1146)
at java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1100)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1241)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at java.io.ObjectOutputStream.writeFatalException(ObjectOutputStream.java:1355)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:281)
上述異常是由于這樣的原因造成的：
1、 客戶端進行查找是NamingContext會建立到命名服務器的Socket連接。（此連接是帶讀取超時的！）
2、 服務器接收了客戶端的連接，使客戶端可以繼續向下運行。于是客戶端運行到ObjectInputStream的readObject處，并等待。此時，客戶端是想要得到NamingServer的stub。
3、 服務端由于線程繁忙，遲遲不能將客戶端需要的stub寫入ObjectOutputStream。于是客戶端等待超時，然后客戶端拋出異常。如果此查找操作是在登錄操作，客戶在登錄失敗后選擇推出程序。則Socket被關閉。
4、 服務端閑下來后調用ObjectOutputStream的writeObject方法，此時由于客戶端Socket關閉，最終拋出上述異常。
這是我們公司的一個牛人分析的，后來察看了JMS也存在類似問題。另：JBOSS的源代碼質量不高，JNDI中存在socket未關閉的情況，JMS代碼中socket用法也很不規范。大家小心了
Hibernate構架應用中常用保存方式區別
Tag：數據庫 pda ie hibernate
下一頁 1 2
hibernate對于對象的保存提供了太多的方法，他們之間有很多不同，這里細說一下，以便區別：
一、預備知識：
在所有之前，說明一下，對于hibernate，它的對象有三種狀態，transient、persistent、detached
下邊是常見的翻譯辦法：
transient：瞬態或者自由態
persistent：持久化狀態
detached：脫管狀態或者游離態
脫管狀態的實例可以通過調用save（）、persist（）或者saveOrUpdate（）方法進行持久化。
持久化實例可以通過調用 delete（）變成脫管狀態。通過get（）或load（）方法得到的實例都是持久化狀態的。
脫管狀態的實例可以通過調用 update（）、0saveOrUpdate（）、lock（）或者replicate（）進行持久化。
save（）和persist（）將會引發SQL的INSERT，delete（）會引發SQLDELETE，而update（）或merge（）會引發SQLUPDATE.對持久化（persistent）實例的修改在刷新提交的時候會被檢測到，它也會引起 SQLUPDATE.saveOrUpdate（）或者replicate（）會引發SQLINSERT或者UPDATE
二、save 和update區別
把這一對放在第一位的原因是因為這一對是最常用的。
save的作用是把一個新的對象保存
update是把一個脫管狀態的對象保存
三、update 和saveOrUpdate區別
這個是比較好理解的，顧名思義，saveOrUpdate基本上就是合成了save和update引用hibernate reference中的一段話來解釋他們的使用場合和區別。
通常下面的場景會使用update（）或saveOrUpdate（）：
程序在第一個session中加載對象
該對象被傳遞到表現層
對象發生了一些改動
該對象被返回到業務邏輯層
程序調用第二個session的update（）方法持久這些改動
saveOrUpdate（）做下面的事：
如果對象已經在本session中持久化了，不做任何事
如果另一個與本session關聯的對象擁有相同的持久化標識（identifier），拋出一個異常
如果對象沒有持久化標識（identifier）屬性，對其調用save（）
如果對象的持久標識（identifier）表明其是一個新實例化的對象，對其調用save（）
如果對象是附帶版本信息的（通過或） 并且版本屬性的值表明其是一個新實例化的對象，save（）它。
四、persist和save區別
這個是最迷離的一對，表面上看起來使用哪個都行，在hibernate reference文檔中也沒有明確的區分他們。
這里給出一個明確的區分。（可以跟進src看一下，雖然實現步驟類似，但是還是有細微的差別）
1.persist把一個瞬態的實例持久化，但是并"不保證"標識符被立刻填入到持久化實例中，標識符的填入可能被推遲到flush的時間。
2.persist"保證"，當它在一個transaction外部被調用的時候并不觸發一個Sql Insert，這個功能是很有用的，當我們通過繼承Session/persistence context來封裝一個長會話流程的時候，一個persist這樣的函數是需要的。
3.save"不保證"第2條，它要返回標識符，所以它會立即執行Sql insert，不管是不是在transaction內部。
五、saveOrUpdateCopy，merge和update區別
首先說明merge是用來代替saveOrUpdateCopy的,然后比較update和merge，update的作用上邊說了，這里說一下merge的作用。
如果session中存在相同持久化標識（identifier）的實例，用用戶給出的對象的狀態覆蓋舊有的持久實例
如果session沒有相應的持久實例，則嘗試從數據庫中加載，或創建新的持久化實例，最后返回該持久實例
用戶給出的這個對象沒有被關聯到session上，它依舊是脫管的
重點是最后一句：
當我們使用update的時候，執行完成后，我們提供的對象A的狀態變成持久化狀態
但當我們使用merge的時候，執行完成，我們提供的對象A還是脫管狀態，hibernate或者new了一個B，或者檢索到一個持久對象，并把我們提供的對象A的所有的值拷貝到這個B，執行完成后B是持久狀態，而我們提供的A還是托管狀態。
六、flush和update區別
這兩個的區別好理解
update操作的是在脫管狀態的對象，而flush是操作的在持久狀態的對象。
默認情況下，一個持久狀態的對象是不需要update的，只要你更改了對象的值，等待hibernate flush就自動保存到數據庫了。hibernate flush發生再幾種情況下：
1.調用某些查詢的時候
2.transaction commit的時候
3.手動調用flush的時候
七、lock和update區別
update是把一個已經更改過的脫管狀態的對象變成持久狀態
lock是把一個沒有更改過的脫管狀態的對象變成持久狀態
對應更改一個記錄的內容，兩個的操作不同：
update的操作步驟是：
更改脫管的對象->調用update
lock的操作步驟是：
調用lock把對象從脫管狀態變成持久狀態——>更改持久狀態的對象的內容——>等待flush或者手動flush