7. 生成主鍵
在EJB之內生成主鍵有許多途徑，下面分析了幾種常見的辦法以及它們的特點。利用數據庫內建的標識機制（SQL Server的IDENTITY或Oracle的SEQUENCE）。這種方法的缺點是EJB可移植性差。由實體Bean自己計算主鍵值（比如做增量操作）。它的缺點是要求事務可串行化，而且速度也較慢。
利用NTP之類的時鐘服務。這要求有面向特定平臺的本地代碼，從而把Bean固定到了特定的OS之上。另外，它還導致了這樣一種可能，即在多CPU的服務器上，同一個毫秒之內生成了兩個主鍵。借鑑Microsoft的思路，在Bean中創建一個GUID。然而，如果不求助於JNI，Java不能確定網卡的MAC地址；如果使用JNI，則程序就要依賴於特定的OS。
還有其他幾種辦法，但這些辦法同樣都有各自的侷限。似乎只有一個答案比較理想：結合運用RMI和JNDI。先通過RMI註冊把RMI遠程對象綁定到JNDI樹。客戶程序通過JNDI進行查找。下面是一個例子：
8. 及時清除不再需要的會話
爲了清除不再活動的會話，許多應用服務器都有默認的會話超時時間，一般爲30分鐘。當應用服務器需要保存更多會話時，如果內存容量不足，操作系統會把部分內存數據轉移到磁盤，應用服務器也可能根據“最近最頻繁使用”（Most Recently Used）算法把部分不活躍的會話轉儲到磁盤，甚至可能拋出“內存不足”異常。在大規模系統中，串行化會話的代價是很昂貴的。當會話不再需要時，應當及時調用HttpSession.invalidate()方法清除會話。HttpSession.invalidate()方法通常可以在應用的退出頁面調用。
9. 在JSP頁面中關閉無用的會話
對於那些無需跟蹤會話狀態的頁面，關閉自動創建的會話可以節省一些資源。使用如下page指令：
10. Servlet與內存使用
許多開發者隨意地把大量信息保存到用戶會話之中。一些時候，保存在會話中的對象沒有及時地被垃圾回收機制回收。從性能上看，典型的症狀是用戶感到系統週期性地變慢，卻又不能把原因歸於任何一個具體的組件。如果監視JVM的堆空間，它的表現是內存佔用不正常地大起大落。解決這類內存問題主要有二種辦法。第一種辦法是，在所有作用範圍爲會話的Bean中實現HttpSessionBindingListener接口。這樣，只要實現valueUnbound()方法，就可以顯式地釋放Bean使用的資源。
另外一種辦法就是儘快地把會話作廢。大多數應用服務器都有設置會話作廢間隔時間的選項。另外，也可以用編程的方式調用會話的setMaxInactiveInterval()方法，該方法用來設定在作廢會話之前，Servlet容器允許的客戶請求的最大間隔時間，以秒計算。
11. HTTP Keep-Alive
Keep-Alive功能使客戶端到服務器端的連接持續有效，當出現對服務器的後繼請求時，Keep-Alive功能避免了建立或者重新建立連接。市場上的大部分Web服務器，包括iPlanet、IIS和Apache，都支持HTTP Keep-Alive。對於提供靜態內容的網站來說，這個功能通常很有用。但是，對於負擔較重的網站來說，這裏存在另外一個問題：雖然爲客戶保留打開的連接有一定的好處，但它同樣影響了性能，因爲在處理暫停期間，本來可以釋放的資源仍舊被佔用。當Web服務器和應用服務器在同一臺機器上運行時，Keep-Alive功能對資源利用的影響尤其突出。
12. JDBC與Unicode
想必你已經瞭解一些使用JDBC時提高性能的措施，比如利用連接池、正確地選擇存儲過程和直接執行的SQL、從結果集刪除多餘的列、預先編譯SQL語句，等等。除了這些顯而易見的選擇之外，另一個提高性能的好選擇可能就是把所有的字符數據都保存爲Unicode（代碼頁13488）。Java以Unicode形式處理所有數據，因此，數據庫驅動程序不必再執行轉換過程。但應該記住：如果採用這種方式，數據庫會變得更大，因爲每個Unicode字符需要2個字節存儲空間。另外，如果有其他非Unicode的程序訪問數據庫，性能問題仍舊會出現，因爲這時數據庫驅動程序仍舊必須執行轉換過程。
在EJB之內生成主鍵有許多途徑，下面分析了幾種常見的辦法以及它們的特點。利用數據庫內建的標識機制（SQL Server的IDENTITY或Oracle的SEQUENCE）。這種方法的缺點是EJB可移植性差。由實體Bean自己計算主鍵值（比如做增量操作）。它的缺點是要求事務可串行化，而且速度也較慢。
利用NTP之類的時鐘服務。這要求有面向特定平臺的本地代碼，從而把Bean固定到了特定的OS之上。另外，它還導致了這樣一種可能，即在多CPU的服務器上，同一個毫秒之內生成了兩個主鍵。借鑑Microsoft的思路，在Bean中創建一個GUID。然而，如果不求助於JNI，Java不能確定網卡的MAC地址；如果使用JNI，則程序就要依賴於特定的OS。
還有其他幾種辦法，但這些辦法同樣都有各自的侷限。似乎只有一個答案比較理想：結合運用RMI和JNDI。先通過RMI註冊把RMI遠程對象綁定到JNDI樹。客戶程序通過JNDI進行查找。下面是一個例子：
public class keyGenerator
extends UnicastRemoteObject implements
Remote { private static long KeyValue = System.currentTimeMillis();
public static synchronized long getKey()
throws RemoteException { return KeyValue++; } |
8. 及時清除不再需要的會話
爲了清除不再活動的會話，許多應用服務器都有默認的會話超時時間，一般爲30分鐘。當應用服務器需要保存更多會話時，如果內存容量不足，操作系統會把部分內存數據轉移到磁盤，應用服務器也可能根據“最近最頻繁使用”（Most Recently Used）算法把部分不活躍的會話轉儲到磁盤，甚至可能拋出“內存不足”異常。在大規模系統中，串行化會話的代價是很昂貴的。當會話不再需要時，應當及時調用HttpSession.invalidate()方法清除會話。HttpSession.invalidate()方法通常可以在應用的退出頁面調用。
9. 在JSP頁面中關閉無用的會話
對於那些無需跟蹤會話狀態的頁面，關閉自動創建的會話可以節省一些資源。使用如下page指令：
<%@ page session="false"%> |
10. Servlet與內存使用
許多開發者隨意地把大量信息保存到用戶會話之中。一些時候，保存在會話中的對象沒有及時地被垃圾回收機制回收。從性能上看，典型的症狀是用戶感到系統週期性地變慢，卻又不能把原因歸於任何一個具體的組件。如果監視JVM的堆空間，它的表現是內存佔用不正常地大起大落。解決這類內存問題主要有二種辦法。第一種辦法是，在所有作用範圍爲會話的Bean中實現HttpSessionBindingListener接口。這樣，只要實現valueUnbound()方法，就可以顯式地釋放Bean使用的資源。
另外一種辦法就是儘快地把會話作廢。大多數應用服務器都有設置會話作廢間隔時間的選項。另外，也可以用編程的方式調用會話的setMaxInactiveInterval()方法，該方法用來設定在作廢會話之前，Servlet容器允許的客戶請求的最大間隔時間，以秒計算。
11. HTTP Keep-Alive
Keep-Alive功能使客戶端到服務器端的連接持續有效，當出現對服務器的後繼請求時，Keep-Alive功能避免了建立或者重新建立連接。市場上的大部分Web服務器，包括iPlanet、IIS和Apache，都支持HTTP Keep-Alive。對於提供靜態內容的網站來說，這個功能通常很有用。但是，對於負擔較重的網站來說，這裏存在另外一個問題：雖然爲客戶保留打開的連接有一定的好處，但它同樣影響了性能，因爲在處理暫停期間，本來可以釋放的資源仍舊被佔用。當Web服務器和應用服務器在同一臺機器上運行時，Keep-Alive功能對資源利用的影響尤其突出。
12. JDBC與Unicode
想必你已經瞭解一些使用JDBC時提高性能的措施，比如利用連接池、正確地選擇存儲過程和直接執行的SQL、從結果集刪除多餘的列、預先編譯SQL語句，等等。除了這些顯而易見的選擇之外，另一個提高性能的好選擇可能就是把所有的字符數據都保存爲Unicode（代碼頁13488）。Java以Unicode形式處理所有數據，因此，數據庫驅動程序不必再執行轉換過程。但應該記住：如果採用這種方式，數據庫會變得更大，因爲每個Unicode字符需要2個字節存儲空間。另外，如果有其他非Unicode的程序訪問數據庫，性能問題仍舊會出現，因爲這時數據庫驅動程序仍舊必須執行轉換過程。
