8 データ・ソースからの物理的な接続の取得

この章では、データ・ソースの物理接続に直接アクセスする方法について説明します。どうしても必要な場合以外は、物理的なJDBC接続へ直接アクセスすることはお薦めしません。

一般的には、WebLogic Serverによって提供される汎用JDBC接続(ラップされた物理的な接続)に対する接続のキャストを行います。これにより、サーバー・インスタンスは接続プールに対する接続の管理、接続プール機能の有効化、およびアプリケーションに提供される接続の品質維持ができるようになります。場合によって、DBMSは物理的な接続(実際のベンダーのJDBC接続)の直接アクセスを必要とする、標準以外の追加のJDBC関連クラスを提供しています。接続プール内の物理的な接続に直接アクセスするには、getVendorConnectionを使用して接続をキャストする必要があります。

注意:

Oracleでは、物理的な接続getVendorConnectionSafeにアクセスするための別のメカニズムも提供します。このメカニズムでも、プールされているデータベース接続(論理接続)からベースとなる物理接続(ベンダー接続)が返されます。ただし、接続を閉じると、「影響のある接続の削除を有効化」の設定に関係なく、プールに返されます。詳細については、「getVendorConnectionSafe」を参照してください。

この章には次の項が含まれます:

接続を開く
接続を閉じる
物理的な接続の使用に関する制限

注意:

どうしても必要な場合以外は、物理的なJDBC接続へ直接アクセスすることはお薦めしません。

接続を開く

物理的なデータベース接続を取得するには、最初に接続プールから接続を取得してから、次のいずれかを実行します。

物理的な接続を必要とするメソッド内で、物理的な接続を暗黙的に渡します(getVendorConnectionを使用)。
接続をWLConnectionにキャストし、getVendorConnectionを呼び出します。

物理的なデータベース接続の直接アクセスは、常にベンダー固有の呼出しの場合に限定します。それ以外のすべての状況では、WebLogic Serverによって提供される汎用JDBC接続を使用します。ベンダー固有の呼出しに対する接続を開くサンプル・コードを次に示します。

例8-1 ベンダー固有の呼出しに対する接続を開くサンプル・コード

//Import this additional class and any vendor packages
//you may need.
import weblogic.jdbc.extensions.WLConnection
.
.
.
myJdbcMethod()
{ 
  // Connections from a connection pool should always be
  // method-level variables, never class or instance methods.
  Connection conn = null; 
   try { 
     ctx = new InitialContext(ht); 
     // Look up the data source on the JNDI tree and request 
     // a connection. 
     javax.sql.DataSource ds 
        = (javax.sql.DataSource) ctx.lookup ("myDataSource"); 
     // Always get a pooled connection in a try block where it is
     // used completely and is closed if necessary in the finally
     // block. 
     conn = ds.getConnection(); 
     // You can now cast the conn object to a WLConnection 
     // interface and then get the underlying physical connection. 
     java.sql.Connection vendorConn = 
       ((WLConnection)conn).getVendorConnection(); 
     // do not close vendorConn
     // You could also cast the vendorConn object to a vendor 
     // interface, such as: 
     // oracle.jdbc.OracleConnection vendorConn = (OracleConnection)
     // ((WLConnection)conn).getVendorConnection()
     // If you have a vendor-specific method that requires the 
     // physical connection, it is best not to obtain or retain 
     // the physical connection, but simply pass it implicitly 
     // where needed, eg:  //vendor.special.methodNeedingConnection(((WLConnection)conn)).getVendorConnection());

接続を閉じる

JDBCでの作業が完了したら、論理的な接続を閉じて、プールに戻す必要があります。物理的な接続を使い終わったら、次の操作を行います。

接続から取得したすべてのオブジェクトを閉じます。
物理的な接続は閉じません。物理的な接続はnullに設定します。

接続をどのように閉じるかは、WebLogic Server管理コンソールで「影響のある接続の削除を有効化」プロパティの値を設定して指定します。これらのオプションの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「JDBCデータ・ソース: 構成: 接続プール」ページを参照するか、Oracle WebLogic Server MBeanリファレンスの「JDBCConnectionPoolParamsBean」を参照してください。

注意:

「影響のある接続の削除を有効化」プロパティは、明示的にgetVendorConnectionを呼び出すアプリケーションに対してのみ適用されます。

例8-2 ベンダー固有の呼出しに対する接続を閉じるサンプル・コード

// As soon as you are finished with vendor-specific calls,  
    // nullify the reference to the connection. 
    // Do not keep it or close it. 
    // Never use the vendor connection for generic JDBC.
    // Use the logical (pooled) connection for standard JDBC. 
    vendorConn = null; 
    ... do all the JDBC needed for the whole method... 
    // close the logical (pooled) connection to return it to 
    // the connection pool, and nullify the reference. 
    conn.close(); 
    conn = null; 
 } 
 catch (Exception e) 
 { 
   // Handle the exception. 
 } 
 finally 
{ 
   // For safety, check whether the logical (pooled) connection
   // was closed. 
   // Always close the logical (pooled) connection as the  
   // first step in the finally block. 
   if (conn != null) try {conn.close();} catch (Exception ignore){} 
 } 
}

「影響のある接続の削除を有効化」がTrueの場合

影響のある接続の削除を有効化がtrue(デフォルト値)のときに論理的な接続を閉じると、サーバー・インスタンスは基底の物理的接続を破棄して、それに取って代わる新しい接続を作成します。このアクションで、プールは次のユーザーに対して、そのユーザーが物理的な接続の唯一のユーザーであることを確実に保証できるようになります。この構成により、接続を閉じるための簡単で安全な方法がもたらされます。ただし、以下の理由により、パフォーマンス上の損失が生じます。

物理的な接続は接続プールの新しいデータベース接続で置き換えられます。このため、アプリケーション・サーバーとデータベース・サーバーの両方でリソースが使用されます。
元の接続のStatementキャッシュが閉じられて、新しい接続用に新しいキャッシュが開かれます。したがって、Statementキャッシュを使用する際のパフォーマンスの利点は失われます。

「影響のある接続の削除を有効化」がFalseの場合

「影響のある接続の削除を有効化」をfalseで使用するのは、公開されている物理的な接続が、論理的な接続を閉じた後、保持または再利用されることが絶対にないと確信している場合のみです。

「影響のある接続の削除を有効化」がfalseのときに論理的な接続を閉じると、サーバー・インスタンスは単に物理的な接続を、再利用のために接続プールに返します。この構成では、パフォーマンス上の損失は最小限に抑えられますが、サーバー・インスタンスは、接続の品質や、論理的な接続が閉じられた後の接続管理の効率を保証はしません。接続が接続プールに返される前に、その接続が他のアプリケーションによる再利用に適していることを確認する必要があります。

物理的な接続の使用に関する制限

接続プールの論理的な接続の代わりに物理的な接続を使用することはお薦めしません。ただし、たとえばSTRUCTの作成などに、物理的な接続を使用する必要がある場合は、以下の負担と制限を考慮してください。

物理的な接続はサーバー側コードでのみ使用できます。
物理的な接続を使用する場合、エラー処理や文のキャッシングなど、WebLogic Serverが提供する接続管理の利点がすべて失われます。
物理的な接続は、それを必要とするベンダー固有のメソッドまたはクラスにのみ使用します。汎用JDBC (文やトランザクション呼出しの作成など)には物理的な接続を使用しないでください。