JDBC連線引數

JDBC連線池的設定：Intial Capcity、Maximum Capacity、Capcity Increment、Allow Shrinking、Test Reserved Connections、Test Created Connections、Test Released Connections、Inactive Connection Timeout

[@more@]JDBC連線池的設定最主要的是Intial Capcity和Maximum Capacity兩個屬性。下面對於JDBC連線池的幾個屬性及最佳化配置方案進行描述：

Initial Capacity: 初始容量，即WebLogic Server在建立連線池的時候建立的連線數量

Maximum Capacity: 最大容量，即WebLogic Server允許的在這個連線池中的連線的最大數量。

通 常，初始容量和最大容量設定為相等，並且不小於執行執行緒的數量。如果你的應用中配置了自定義執行執行緒佇列，那麼就要計算全部的用來給應用工作的執行緒的數 量。如此設定才能夠起到Pool的作用，避免在應用執行過程中出現建立JDBC連線的請求。因為建立JDBC連線對於WebLogic Server和資料庫伺服器來說，都是開銷比較大的動作。如果應用中存在在一個執行緒中獲取多個連線的情況，那麼初始容量和最大容量應該大於執行執行緒的數 量，甚至需要成倍增加。比如下面的JSP程式碼就會導致一個執行緒工作佔用2個連線：

ctx = new InitialContext();
ds = (DataSource)ctx.lookup(”lab.ds.pbjade”);
conn = ds.getConnection();
// do some query operations

conn2 = ds.getConnection();
// do some query operations

以 上這段程式碼，在執行過程中，第一個連線conn關閉之前，又獲取了第二個連線conn2，這樣一來，這個JSP頁面在執行的時候（由一個執行緒來執行），會 同時獲取2個連線，連線池容量的最最佳化設定是執行執行緒的數量的2倍。因為在極端情況下，如果在同一時刻，所有的請求都指向這個頁面，那麼就需要執行執行緒數 量2倍的連線才不會出現連線等待。

Capcity Increment: 增長步長。如果初始容量和最大容量不相等，並且需要更多的連線時，WebLogic Server一次建立新連線的數量。

Allow Shrinking: 允許自動收縮。如果連線池的初始容量和最大容量不相等，那麼當池中的連線大於初始容量時，經過Shrink Frequency時間，如果連線池中的活動連線不高於初始容量個，那麼連線池中連線的數量會減少到初始容量大。

上面這幾個引數是配置相關的，通常Initial Capacity=Maximum Capacity 並且>=執行執行緒的數量，並且不選擇Allow Shrinking選項，避免不必要的週期檢查。

如 果WebLogic Server和資料庫伺服器之間的網路連線不穩定，或者兩個伺服器之間存在防火牆，導致JDBC連線不穩定，WebLogic Server還提供了一些測試策略以儘量保證應用難道的連線是有效的。主要有3個選項：Test Reserved Connections、Test Created Connections、Test Released Connections。測試的時機分別是應用獲取連線、WebLogic Server建立連線、應用釋放連線。通常這3個選項只需選擇Test Reserved Connections即可，無需全部選擇。根據測試資料，可能會有3%左右的效能下降。所以如果不是必要，也不必使用這些選項。

在 使用JDBC連線池的過程中，最常見的一個問題就是連線池洩漏問題。一個池裡面的資源是有限的，應用用完之後應該還回到池中，否則池中的資源會被耗盡。 WebLogic Server提供了一個Inactive Connection Timeout選項，預設是60秒，如果一個連線被應用拿走之後，超過這個時間還沒有還回來，WebLogic Server會強制將這個連線回收。如果應用中不存在連線洩漏的問題，則不需要這個選項。設定為0即可禁用。

總結一下，連線池的設定相對比較簡單，主要是初始容量及最大容量兩個引數。其他的選項不需要的可以去掉，避免不必要的效能開銷。