連線儲存區

使用連線儲存區有助於減輕連線管理的成本及減少資料存取的開發工作。

每次應用程式嘗試存取後端儲存庫（如資料庫）時，它都會要求資源建立、維護和釋出這個資料儲存庫的連線。為了緩和這個程序可能會加在整體應用程式資源上的負荷，應用程式伺服器可讓管理者建立一個後端連線儲存區，供各應用程式在應用程式伺服器上共用這些連線。連線儲存區會將連線的額外負荷分散給多個使用者要求，從而能夠節省應用程式資源，供未來的要求使用。

應用程式伺服器支援用於連線儲存區和重複使用連線的 JDBC 4.0 API。連線儲存區用來導引應用程式內的 JDBC 呼叫，也供使用資料庫的 Enterprise Bean 使用。

連線儲存區的優點

連線儲存區可以改進任何需要連線的應用程式的回應時間，尤其是 Web 型應用程式。當使用者透過 Web 發出資源要求時，這個資源會存取一個資料來源。由於在網際網路中，使用者會經常連接應用程式，再切斷連線，因此，存取資料的應用程式要求數量可能會很大。因此，Web 型應用程式的資料儲存庫額外負荷總量會變成很高，效能會退化。不過，當使用連線儲存區功能時，Web 應用程式的效能最大可達正常結果的 20 倍。

當使用連線儲存區時，大部分使用者要求都不需要承擔建立新連線的成本，因為資料來源可以尋找和使用連線儲存區中現有的連線。當要求獲得滿足且回應傳回給使用者之後，資源會將連線傳回連線儲存區，供未來使用。這可以避免斷線的額外負荷。每個使用者要求都會承擔一小部分的連線或切斷連線的成本。在利用起始資源產生儲存區中的連線之後，其他成本就不再重要，因為現有的連線會重複使用。

連線儲存區的使用時機

請在符合下列任一準則的應用程式中，使用連線儲存區：

無法容忍每次使用連線時都要花費取得和釋出連線的成本。
它需要應用程式伺服器內的 Java™ 交易 API (JTA) 交易。
需要多個使用者在相同交易內共用連線。
需要利用產品功能在應用程式伺服器中管理區域交易。
不會管理它自己的連線儲存區。
不管理建立連線的特定項目，如：資料庫名稱、使用者名稱或密碼。

避免麻煩: 應用程式用戶端不支援連線儲存區。應用程式用戶端會直接呼叫資料庫，並不透過資料來源。如果您要從應用程式用戶端使用 getConnection() 要求，請利用 Rational® Application Developer 或組合工具，在應用程式用戶端部署描述子中配置 JDBC 提供者。連線是建立在應用程式用戶端和資料庫之間。應用程式用戶端並沒有連線儲存區，但您可以在用戶端部署描述子中配置 JDBC 提供者設定。

如何將連線一起放在儲存區中

當您配置唯一的資料來源或 Connection Factory 時，必須為它提供唯一的「Java 命名和目錄介面 (JNDI)」名稱。這個 JNDI 名稱及其配置資訊用來建立連線儲存區。每個配置的資料來源或 Connection Factory 都有一個個別的連線儲存區。

此外，應用程式伺服器還會在每個使用資料來源或 Connection Factory 的應用程式伺服器中，建立個別的連線儲存區實例。例如：

如果您執行三部伺服器叢集，其中所有伺服器都使用 myDataSource，且 myDataSource 的「連線數上限」設定為 10 ，則您最多可以產生 30 條連線 (三部伺服器乘以 10 條連線)。

請考量這個行為可能對後端資源所能支援的連線數目的影響。如需相關資訊，請參閱「連線儲存區設定」主題。

決定連線數上限設定的其他考量:

每項 Entity Bean 交易都需要專用來處理交易的額外資料庫連線。
如果使用複本，則每一個複本都會有一個資料儲存區。
在支援的 UNIX 系統上，會針對每一個連線建立個別 DB2® 處理程序; 這些處理程序會在記憶體不足且導致錯誤的系統上快速影響效能。

還有很重要的一點是，在使用連線共用時，只能共用從相同連線儲存區取得的連線。