什麼時候用有狀態session bean,什麼時候用無狀態session bean (轉)

什麼時候用有狀態session bean,什麼時候用無狀態session bean (轉)[@more@]

什麼時候用有狀態session bean,什麼時候用無狀態session bean

最近，有關於無狀態的許多大驚小怪。無狀態的缺陷常常被誇大，
它的優點也一樣。許多無狀態的支持者盲目的宣稱無狀態能帶來
更大的伸縮性；而有狀態的支持者爭論說必須為了適應無狀態
而重建整個。真實的情況是什麼呢？

透過正確地設計，無狀態有以下兩個優點：
1.使用stateless bean,容器能容易的pooling和重用bean,
允許少量的bean去服務很多客戶端。用stateful bean去做同樣
的事情時，bean的狀態在方法之間必需要鈍化和活化，可
能導致I/O瓶頸。所以無狀態的一個實際的好處是使用很小的
開銷來容易的pool和重用。

2.因為一個stateful session bean在中緩衝一個客戶端
的對話，一個bean失敗可能導致失去你的對話。這能導致嚴重
的反響，如果你不在寫bean時考慮到這一點，或者你不使用一
個提供有狀態恢復的EJB產品。在一個無狀態模型裡面，請求
能被透明的重到一個不同的元件，因為任何元件都能為
客戶端的需要提供服務。

  最大的無狀態的缺點是你需要在每個方法呼叫中把客戶相關的
的資料推到stateless bean。大多數stateless session bean
將需要接收對一個客戶端特定的一些資訊，如對banking bean的
銀行帳戶號碼。這些資訊要每次一個客戶端請求到達時被提供到
stateless bean，因為bean不能對一個特定的客戶端保持狀態。

  一種向bean提供客戶相關的資料的方法是把資料作為引數傳到
bean的方法中。這可能導致下降，然而，只是發生在傳遞的
資料量很大的情況下。這也阻塞了，降低了其他程式的頻寬。

  另一種為stateless bean提供客戶相關的資料的方法，為那個
bean為一個客戶端永續性的資料。客戶端不需要在一個方法
呼叫中傳遞所有的狀態，而只簡單的需要從持久化的storage得到
資料。這裡的trade-off又是效能：儲存對話持久化的能得到儲存
I/O瓶頸，而不是網路I/O瓶頸。

  再一種超越無狀態的限制的方法是使用JNDI去儲存客戶相關資料
到一個目錄結構。客戶端能夠等一會傳給bean一個在目錄結構定位
資料的標識。這和儲存資料到很相似。比較大的區別是JNDI
實現能是一個in-memory實現(和共享屬性管理器有相同作用，對
com+讀者來說應該很熟悉)。如果資料存在記憶體中，沒有資料庫會
碰上。

  當從有狀態和無狀態之間選擇，你應該問你自己商業程式展開
多呼叫，需要一個對話？如果是這樣，有狀態模型應該很合適因
為客戶相關的對話能成為bean狀態的一部分。相反，如果你的商業
程式變成一個方法呼叫，無狀態能更適合你的需要。

  注意如果你要去使用狀態，並且你要去建一個基於的系統，
你可能可以用一個的HttpSession去做到這一點，和
stateful session bean大致一樣。該用stateful session bean
而不是HttpSession的情況如下：
1.你需要一個事務感知的有狀態物件。你的session bean能用
SessionSynchronization來做到這一點。

2.你既有基於web的也有不基於web的客戶端來存取你的EJB層，
而且都需要狀態。

3.你在使用一個stateful session bean來暫時儲存一個商業程式
的暫時狀態，這發生在牽扯到多個bean的單個Http請求中。

  綜上所述，大多數先進的deployment要有複雜而有趣的有狀態的
和無狀態的組合。使用對你的商業問題最合適的。一個例外是如果
有一個明顯的瓶頸，如保持成兆的狀態在記憶體中。而如果你在選擇
有狀態還是無狀態，你會發現有狀態可能不是你的首要問題:直到
你測試你的程式碼，你還在黑暗中亂開槍。如果有狀態是你的瓶頸，
如果有必要，你可以重構你的程式碼。