http://www-900.ibm.com/developerWorks/cn/java/j-pathcol/
筆記：
實體bean VS sessionBean＋JDBC
讀／寫需要。需要經常讀取且從不更改或偶爾更改的數據最好由會話 bean 與 JDBC 組合來處理。開發工作會簡單直接，併產生極好的響應時間。如果數據需要頻繁更新並支持許多併發請求（因此有許多併發更改），那麼實體 bean 是當然的選項。在面對數據的併發請求時，爲確保數據完整性、同步和頻繁的持久性而構建一種機制所涉及的複雜性簡直太難克服了，而且不值得花時間和精力來創建它。
事務支持。CMP 實體 bean 使開發人員不必關心事務環境。所有事務細節都在 bean 的部署描述符中聲明。如果可以接受這一級別的控制，那麼 CMP 實體 bean 無疑提供了最容易的解決方案。如果需要更多的控制，那麼 BMP bean 允許開發人員定義應該採取的操作，而不必爲應該何時觸發這類操作來編寫業務規則。對於最大級別的控制，應該使用會話 bean。會話 bean 會管理涉及 CMP 和 BMP 實體 bean 的複雜事務，以及少數直接訪問數據庫的 JDBC 調用。
上市時間。CMP 實體 bean 顯然是所有 J2EE 持久性機制中唯一一個上市時間最快的。聲明數據類型和名稱，定義部署設置，然後由應用程序服務器和供應商工具負責其餘部分。很難講 BMP 實體 bean 和會話 bean 與 JDBC 組合哪個能排上第二快的解決方案。一方面，BMP 會更快，因爲容器正代表 bean 提供如此多的生命週期服務。而另一方面，會話 bean 會領先，因爲它們沒有 BMP 那麼複雜，所以構建／測試／部署週期更短。最後，在這三種解決方案針對您的特定項目時給它們排序只是整個比較過程的一部分。還必須針對下一個類別（資源使用情況）來權衡這個評級。
資源使用情況。實體 bean 因消耗大量的資源（尤其對特別大的實體進行併發請求時）而聲名狼籍。與之相比，會話 bean 和 JDBC 數據源連接是非常輕量級的，只需要少量的服務器資源。有關這一點的更多信息，請閱讀本系列的第一篇文章“J2EE technologies for the stateless network”（請參閱參考資料中的 J2EE Pathfinder 系列文章）中概述的無狀態會話 EJB 實例-合用模型描述。