WebLogic Type 4 JDBC ドライバ ガイド

MS SQL Server ドライバ

以下の節では、WebLogic Type 4 JDBC SQL Server ドライバのコンフィグレーション方法と使用方法について説明します。

サポートされる SQL Server データベースのバージョン

WebLogic Type 4 JDBC MS SQL Server ドライバ (「SQL Server ドライバ」) は、以下のバージョンのデータベース管理システムをサポートします。

JTA を介して JDBC 分散トランザクションを使用するには、Microsoft SQL Server のストアド プロシージャをインストールする必要があります。詳細については、「JTA 用ストアド プロシージャのインストール」を参照してください。

ドライバ クラス

WebLogic Type 4 JDBC MS SQL Server のドライバ クラスは次のとおりです。

   XA : weblogic.jdbcx.sqlserver.SQLServerDataSource

   非 XA : weblogic.jdbc.sqlserver.SQLServerDriver

Microsoft SQL Server の URL

Microsoft SQL Server データベースに接続するには、次の形式の URL を使用します。

jdbc:bea:sqlserver://hostname:port[;property=value[;...]]

各要素の説明は次のとおりです。

次に例を示す。

jdbc:bea:sqlserver://server1:1433;User=test;Password=secret

名前付きインスタンスに接続する手順については、「名前付きインスタンスへの接続」を参照してください。

名前付きインスタンスへの接続

Microsoft SQL Server および Microsoft SQL Server 2005 では、SQL Server データベースの複数のインスタンスを同じサーバで同時に実行することができます。各インスタンスはインスタンス名で識別されます。

接続 URL を使用して名前付きのインスタンスに接続するには、次の形式で URL を指定します。

   jdbc:bea:sqlserver://server_name\\instance_name 

各値の説明は次のとおりです。

   server_name は、サーバの IP アドレスまたはホスト名です。

   instance_name は、サーバ上の接続先インスタンスの名前です。

たとえば次の接続 URL を指定すると、server1 上の instance1 に接続されます。

   jdbc:bea:sqlserver://server1\\instance1;User=test;Pasword=secret

SQL Server 接続プロパティ

表 5-1 に、SQL Server ドライバでサポートされる JDBC 接続プロパティを示し、各プロパティについて説明します。WebLogic Server ドメインの JDBC データ ソースのコンフィグレーションでこれらの接続プロパティを使用できます。プロパティを指定するには、JDBC データ ソースのコンフィグレーションで次の形式を使用します。

   property=value

jdbc:bea:sqlserver://server3:1433;
DatabaseName=test;LoadLibraryPath=C:\DataDirect\lib;
User=test;Password=secret

パフォーマンスに関する考慮事項

以下に示すように SQL Server ドライバの接続プロパティを設定すると、アプリケーションのパフォーマンスを向上させることができます。

EncryptionMethod

データの暗号化と復号化により余分なオーバーヘッド (主に CPU の使用率) がかかるため、パフォーマンスが低下する場合があります。

InsensitiveResultSetBufferSize

スクロールインセンシティブな結果セットを使用する場合のパフォーマンスを向上させるため、ドライバは結果セット データをディスクに書き込む代わりに、メモリにキャッシュできます。デフォルトでは、ドライバはインセンシティブな結果セット データを 2 MB までメモリにキャッシュし、残りの結果セット データをディスクに書き込みます。パフォーマンスを向上させるには、ドライバがデータをディスクに書き込む前に使用するメモリの量を増やすか、ドライバがインセンシティブな結果セット データをディスクに書き込めないようにします。最大キャッシュ サイズの設定は 2 GB です。

LongDataCacheSize

アプリケーションが画像、ピクチャ、長いテキスト、またはバイナリ データを取得するときのパフォーマンスを向上させるために、アプリケーションが長いデータ カラム値を結果セット内での定義順に取得する場合は、クライアントで長いデータのキャッシュを無効にすることができます。アプリケーションが長いデータ カラム値を順不同で取得する場合は、長いデータ値をクライアントでキャッシュする必要があります。この場合は、データをディスクに書き込む前にドライバによって使用されるメモリの容量を増やすことで、パフォーマンスを改善できます。

PacketSize

通常、クライアントはサーバで許可されている最大パケット サイズを使用するのが適しています。これにより、クライアントへデータを返すために必要な往復回数が減るため、パフォーマンスが向上します。つまり、このプロパティにデータベース サーバの最大パケット サイズを設定すると、パフォーマンスを向上させることができます。

ResultSetMetaDataOptions

デフォルトでは、ResultSetMetaData.getTableName() メソッドが呼び出された場合、SQL Server ドライバは、結果セット内の各カラムの正しいテーブル名を返すために必要な追加の処理を省略します。このため、getTableName() メソッドは結果セット内のカラムごとに空の文字列を返す可能性があります。アプリケーションでテーブル名情報が必要ない場合は、この設定によって最適なパフォーマンスが得られます。

ResultSet メタデータを返す方法の詳細については、「ResultSet メタデータのサポート」を参照してください。

SelectMethod

ほとんどの場合、サーバサイドのデータベース カーソルを使用するとパフォーマンスに悪影響を与えます。ただし、アプリケーションが次のような条件に該当する場合は、このプロパティの最適な設定は cursor です。この設定は、サーバサイドのデータベース カーソルを使用することを表します。

SendStringParametersAsUnicode

アプリケーションによってアクセスされるすべてのデータが、デフォルトのデータベースの文字エンコーディングを使用してデータベースに格納される場合、SendStringParametersAsUnicode の設定を false にするとパフォーマンスを向上させることができます。

SnapshotSerializable

このプロパティを機能させるには、Microsoft SQL Server 2005 データベースで Snapshot アイソレーションをコンフィグレーションする必要があります。詳細については、「スナップショット アイソレーション レベルの使用 (Microsoft SQL Server 2005 のみ)」を参照してください。

Snapshot アイソレーションでは、データが変更されるまでデータのロックを取得しないことで、トランザクションレベルの読み込みの一貫性とオプティミスティックなデータ変更手法を提供します。別のトランザクションがデータを変更していても一貫して同じ結果セットを返したい場合で、1) アプリケーションで多数の読み込み操作を実行する場合、または、2) アプリケーションに長期間のトランザクションがあり、そのトランザクションがユーザによるデータの読み込みをブロックするする可能性がある場合は、この Microsoft SQL Server 2005 の機能が役立つ可能性があります。この機能を使用すると、読み込み操作と更新操作の間のデータ競合が排除される可能性があります。この接続プロパティを true に設定する (その結果、Snapshot アイソレーションを使用する) 場合、同時実効性が上がるためパフォーマンスが向上します。

UseServerSideUpdatableCursors

ほとんどの場合、サーバサイドで更新可能なカーソルを使用するとパフォーマンスが向上します。ただし、このタイプのカーソルは、インセンシティブな結果セット、または主キーを含むデータベース テーブルから生成されていないセンシティブな結果セットで使用することはできません。

サーバサイドで更新可能なカーソルの使用方法については、「サーバサイドで更新可能なカーソル」を参照してください。

データ型

表 5-2 に、SQL Server ドライバでサポートされる SQL Server 7 および SQL Server 2000 のデータ型と、対応する JDBC データ型を示します。

データ型の詳細については、「getTypeInfo」を参照してください。

返される XML データとその挿入/更新

Microsoft SQL Server 2005 では、SQL Server ドライバで XML データ型がサポートされます。XML データ型は、デフォルトでは JDBC LONGVARCHAR データ型にマップされますが、XMLDescribeType 接続プロパティの値を longvarbinary に設定することで LONGVARCHAR データ型にマップすることも可能です。

返される XML データ

ドライバからは、XML データを文字データまたはバイナリ データとして返すことができます。たとえば、あるデータベース テーブルを次のように定義したとします。

CREATE TABLE xmlTable (id int, xmlCol xml NOT NULL)

そして、次のようにコーディングしたとします。

String sql="SELECT xmlCol FROM xmlTable";

ResultSet rs=stmt.executeQuery(sql);

この場合、データベースから返される XML データが文字データになるかバイナリ データになるかは、XMLDescribeType プロパティの設定によって決まります。XMLType データ型は、デフォルトでは JDBC LONGVARCHAR データ型にマップされます。次の接続 URL で XML データ型が LONGVARBINARY データ型にマップされている場合は、ドライバによって返される XML データが文字データではなくバイナリ データになります。

jdbc:bea:sqlserver://server1:1433;DatabaseName=jdbc;User=test;
Password=secret;XMLDescribeType=longvarbinary

文字データ

XMLDescribeType=longvarchar に設定した場合、XML データは文字データとして返されます。結果セット カラムは、カラム型の LONGVARCHAR で表現され、カラム型名は xml となります。

XMLDescribeType=longvarchar に設定した場合は、アプリケーションで以下のメソッドを使用することで、XML カラムに文字データとして格納されているデータを返すことができます。

ResultSet.getString()
ResultSet.getCharacterStream()
ResultSet.getClob()
CallableStatement.getString()
CallableStatement.getClob()

データベース サーバから返された XML データは、データベース サーバで使用する UTF-8 エンコーディングから、UTF-16 Java 文字列エンコーディングに変換されます。

アプリケーションで次のメソッドを使用することで、XML カラムに ASCII データとして格納されているデータを返すことができます。

ResultSet.getAsciiStream()

データベース サーバから返された XML データは、データベース サーバで使用する UTF-1 エンコーディングから、ISO-8859-1 (latin1) エンコーディングに変換されます。

XMLDescribeType=longvarbinary に設定した場合は、この節で説明した文字データ用のメソッドを使用しないでください。使用すると、JDBC 文字からバイナリへの標準の変換がデータに適用され、文字データの 16 進表現が返されます。

バイナリ データ

XMLDescribeType=longvarbinary に設定した場合、XML データはバイナリ データとして返されます。結果セット カラムは、カラム型の LONGVARBINARY で表現され、カラム型名は xml となります。

アプリケーションで以下のメソッドを使用して、XML データをバイナリ データとして返すことができます。

ResultSet.getBytes()
ResultSet.getBinaryStream()
ResultSet.getBlob()
ResultSet.getObject()
CallableStatement.getBytes()
CallableStatement.getBlob()
CallableStatement.getObject()

データベース サーバから返される XML データにはデータ変換は適用されません。これらのメソッドは、UTF-8 としてエンコードされた XML データを格納するバイト配列またはバイナリ ストリームを返します。

XMLDescribeType=longvarchar に設定した場合は、この節で説明した文字データ用のメソッドを使用しないでください。使用すると、JDBC バイナリから文字への標準の変換がデータに適用され、バイナリ データの 16 進表現が返されます。

XML データの挿入と更新

ドライバからは、XML データを文字データまたはバイナリ データとして挿入または更新できます。

文字データ

アプリケーションで以下のメソッドを使用することで、XML データを文字データとして挿入または更新できます。

PreparedStatement.setString()
PreparedStatement.setCharacterStream()
PreparedStatement.setClob()
PreparedStatement.setObject()
ResultSet.updateString()
ResultSet.updateCharacterStream()
ResultSet.updateClob()
ReultSet.updateObject()

データの文字表現がデータベース サーバで使用する XML 文字セットに変換され、変換後の XML データがサーバに送信されます。XML 処理手順が、ドライバによって解析されたり削除されたりすることはありません。

アプリケーションで以下のメソッドを使用することで、XML データを ASCII データとして更新できます。

PreparedStatement.setAsciiStream()
ResultSet.updateAsciiStream()

これらのメソッドに返すデータは、ISO-8859-1 (latin 1) エンコーディングで解釈されます。ISO-8859-1 のデータがデータベース サーバで使用する XML 文字セットに変換され、変換後の XML データがサーバに送信されます。

バイナリ データ

アプリケーションで以下のメソッドを使用することで、XML データをバイナリ データとして挿入または更新できます。

PreparedStatement.setBytes()
PreparedStatement.setBinaryStream()
PreparedStatement.setBlob()
PreparedStatement.setObject()
ResultSet.updateBytes()
ResultSet.updateBinaryStream()
ResultSet.updateBlob()
ReultSet.updateObject()

XML データがデータベース サーバに送信される際に、データ変換が適用されることはありません。

認証

認証では、ユーザの識別情報を保護することで、悪意のあるハッカーが転送中のユーザ資格を傍受できないようになっています。概要については「認証」を参照してください。

SQL Server ドライバでは、以下の認証方法がサポートされます。

NTLM 認証 (Windows クライアントの認証のみを提供) を除いて、ドライバがサポート対象のプラットフォームで実行されている場合、これらの認証方法で認証が提供されます。

AuthenticationMethod 接続プロパティは、ドライバが接続を確立する際に使用する認証メカニズムを指定するために使用します。このプロパティに設定する値の詳細については、「AuthenticationMethod プロパティの使用」を参照してください。

AuthenticationMethod プロパティの使用

AuthenticationMethod 接続プロパティは、ドライバが接続を確立する際に使用する認証メカニズムを指定するために使用します。AuthenticationMethod=auto の場合、ドライバは以下の条件に基づいて、接続を確立する際に SQL Server 認証、Kerberos 認証、または NTLM 認証を使用します。

AuthenticationMethod=kerberos に設定すると、接続を確立する際に Kerberos 認証が使用されます。User プロパティと Password プロパティに指定された値は無視されます。

AuthenticationMethod=ntlm の場合は、ドライバが NTLM 認証に必要な DLL をロードできる場合、ドライバは接続を確立する際に NTLM 認証を使用します。DLL をロードできない場合は、ドライバから例外が送出されます。User プロパティと Password プロパティに指定された値は無視されます。

AuthenticationMethod=userIdPassword (デフォルト) に設定すると、接続を確立する際に SQL Server 認証が使用されます。User プロパティはユーザ ID を提供します。Password プロパティはパスワードを提供します。ユーザ ID が指定されていない場合は、ドライバから例外が送出されます。

SQL Server 認証のコンフィグレーション

Kerberos 認証のコンフィグレーション

この節では、Microsoft SQL Server ドライバに Kerberos 認証をコンフィグレーションする場合の要件と手順について説明します。

製品要件

ドライバに Kerberos 認証をコンフィグレーションする前に、使用している環境が 表 5-3 の要件を満たしていることを確認してください。

ドライバをコンフィグレーションする

WebLogic Server JDBC ドライバをインストールする際には、Kerberos 認証で必要となる以下のファイルが WL_HOME/server/lib フォルダにインストールされます。なお、WL_HOME は WebLogic Server のインストール ディレクトリです。

ドライバをコンフィグレーションするには

SQL Server ドライバでの Windows 認証用に環境をコンフィグレーションおよびテストする方法については、以下の URL を参照してください。

http://www.datadirect.com/developer/jdbc/index.ssp

Kerberos 認証のユーザ資格の指定 (資格の委託)

デフォルトでは、オペレーティング システムに保持されているユーザ ID とパスワードを使用して、データベースにアクセスするユーザの認証が行われます。オペレーティング システムで使用されているユーザ名とパスワードをデータベースでも使用できるため、有効なオペレーティング システム アカウントにログインしているユーザであれば、ユーザ名とパスワードを入力せずにデータベースにログインできます。

オペレーティング システムのユーザ名とパスワード以外のユーザ資格セットを使用したい場合もあります。たとえば、アプリケーション サーバや Web サーバの多くは、サーバ ユーザとしてではなく、アプリケーションが実行されているマシンにログオンしたクライアント ユーザの代理として処理を実行します。

オペレーティング システムのユーザ名とパスワード以外のユーザ資格セットを使用する場合は、次のようなコードをアプリケーションに追加し、認証に使用する javax.security.auth.Subject を取得してドライバに渡します。

import javax.security.auth.Subject;
import javax.security.auth.login.LoginContext;
import java.sql.*;

//  ここでは、認証に使用する javax.security.auth.Subject
//  インスタンスを作成する。LoginContext を使用して
// Subject を取得する方法の詳細については、JAAS (Authentication and 
//  Authorization Service) のドキュメントを参照。

LoginContext lc = null;
Subject subject = null;

try {

    lc = new LoginContext("JaasSample", new TextCallbackHandler());
    lc.login();
    subject = lc.getSubject();
} 
catch (Exception le) {
    ... // ログイン エラーを表示する。
}

// このアプリケーションは、ドライバ コードをサブジェクトとして実行することで、
// javax.security.auth.Subject をドライバに渡す。

Connection con = 
   (Connection) Subject.doAs(subject, new PrivilegedExceptionAction() {
    
    public Object run() {
    
        Connection con = null;
    try {

         Class.forName("com.ddtek.jdbc.sqlserver.SQLServerDriver");
         String url = "jdbc:bea:sqlserver://myServer:1433";
         con = DriverManager.getConnection(url);
        }
     catch (Exception except) {

     ... // 接続エラーをログに記録する。
           return null;
        }
        
        return con;
    }
});

// これで、このアプリケーションで使用する接続がサブジェクトを使用して
// 認証されたことになる。これにより、アプリケーションで接続を使用できるようになる。
Statement   stmt = con.createStatement();
String      sql = "select * from employee";
ResultSet   rs = stmt.executeQuery(sql);

... // 結果に基づいて処理を行う。

Kerberos チケット認可チケットの取得

アプリケーション ユーザが Kerberos 認証を使用する場合は、まず Kerberos サーバから Kerberos チケット認可チケット (TGT) を取得する必要があります。Kerberos サーバでは、TGT に格納されている資格を使用して、ユーザの識別情報を検証し、サービスへのアクセスを制御します。

Windows クライアント上のアプリケーションから Kerberos 認証を使用する場合は、アプリケーション ユーザが Kerberos サーバにログオンして明示的に TGT を取得する必要はありません。ユーザの TGT は、Windows Active Directory によって自動的に取得されます。

UNIX または Linux クライアント上のアプリケーションから Kerberos 認証を使用する場合、ユーザは kinit コマンドを使用して Kerberos サーバにログオンし、明示的に TGT を取得する必要があります。たとえば、次に示すコマンドは、有効期間が 10 時間で 5 日間更新可能な TGT をサーバに要求しています。

kinit -l 10h -r 5d user

ここで、user はアプリケーション ユーザです。

kinit コマンドの使用とユーザの TGT の取得については、Kerberos ドキュメントを参照してください。

NTLM 認証のコンフィグレーション

この節では、DB ドライバに NTLM 認証をコンフィグレーションする場合の要件と手順について説明します。

製品要件

環境で NTLM 認証をコンフィグレーションする前に、使用している環境が 表 5-4 の要件を満たしていることを確認してください。

ドライバをコンフィグレーションする

WebLogic Type 4 JDBC ドライバは以下の NTLM 認証 DLL を提供しています。

xx は 2 桁の数字です。

DLL は WL_HOME/server/lib ディレクトリにあります (WL_HOME は WebLogic Server のインストール先ディレクトリ)。NTLM 認証を使用するアプリケーションが 32 ビット JVM で実行されている場合は、自動的に DDJDBCAuthxx.dll が使用されます。同様に、アプリケーションが 64 ビット JVM で実行されている場合は、DDJDBC64Authxx.dll または DDJDBCx64Authxx.dll が使用されます。

ドライバをコンフィグレーションするには

データの暗号化

SQL Server ドライバでは、データ暗号化で SSL がサポートされます。SSL が提供する暗号化と認証によって、データの整合性を確保できます。詳細については、「ネットワーク上でのデータの暗号化」を参照してください。

Microsoft SQL Server のコンフィグレーションに応じて、ログイン リクエストを含むすべてのデータを暗号化するか、ログイン リクエストのみを暗号化するかを選択できます。データではなくログイン リクエストを暗号化する方法は、以下のシナリオで有用です。

Microsoft SQL Server での SSL の使用

Microsoft SQL Server データベース サーバで信頼性のある CA によって署名された SSL 証明書がコンフィグレーションされている場合、サーバでは SSL 暗号化を省略可能または必須としてコンフィグレーションできます。必須の場合、SSL 暗号化をサポートしていないクライアントからの接続は失敗します。

最高水準のセキュリティには署名済みの信頼性のある SSL 証明書をお勧めしますが、Microsoft SQL Server 2005 では、サーバで SSL 証明書がコンフィグレーションされていない場合でも、限定的なセキュリティ保護を提供できます。信頼性のある証明書がインストールされていない場合、サーバは自己署名証明書を使用してデータではなくログイン リクエストを暗号化します。

表 5-5 では、EncryptionMethod プロパティの各値と Microsoft SQL Server の各種コンフィグレーションに応じた動作を示します。

SSL 暗号化のコンフィグレーション

結果を返す DML (Microsoft SQL Server 2005)

SQL Server ドライバでは、Insert、Update、および Delete 文で Microsoft SQL Server 2005 の Output 句をサポートします。たとえば、以下の文でテーブルを作成したとします。

CREATE TABLE table1(id int, name varchar(30))

以下の Update 文では、table1 の id カラムの値を更新し、古い ID (新しい ID で置換される)、新しい ID、これらの ID に関連付けられた名前を含む結果セットを返します。

UPDATE table1 SET id=id*10 OUTPUT deleted.id as oldId, inserted.id as newId, inserted.name

ドライバは別の結果セットで Insert、Update、または Delete 文の結果と更新回数を返します。出力結果セットが最初に返され、続いて Insert、Update、または Delete 文の結果が返されます。結果を返す DML をアプリケーション内で実行するには、Statement.execute() または PreparedStatement.execute() メソッドを使用します。その後に Statement.getMoreResults () を使用して、出力結果セットと更新回数を取得します。次に例を示します。

String sql = "UPDATE table1 SET id=id*10 OUTPUT deleted.id as oldId,
   inserted.id as newId, inserted.name";
boolean isResultSet = stmt.execute(sql);

int   updateCount = 0;
while (true) {

   if (isResultSet) {
         resultSet = stmt.getResultSet();
         while (resultSet.next()) {

            System.out.println("oldId: " + resultSet.getInt(1) + 
                               "newId: " + resultSet.getInt(2) + 
                               "name: " + resultSet.getString(3));
         }
         resultSet.close();
   }
   else {
         updateCount = stmt.getUpdateCount();
         if (updateCount == -1) {
            break;
         }

         System.out.println("Update Count: " + updateCount);
   }

   isResultSet = stmt.getMoreResults();
}

SQL エスケープ シーケンス

SQL Server ドライバでサポートされている SQL エスケープ シーケンスについては、「JDBC の SQL エスケープ シーケンス」を参照してください。

アイソレーション レベル

SQL Server ドライバは Microsoft SQL Server の以下のアイソレーション レベルをサポートします。

* Microsoft SQL Server 2005 でのみサポート

デフォルトは Read Committed with Locks (Microsoft SQL Server 2005) または Read Committed です。

スナップショット アイソレーション レベルの使用 (Microsoft SQL Server 2005 のみ)

Snapshot アイソレーション レベルは以下のいずれかの方法で使用できます。

スクロール可能なカーソルの使用

SQL Server ドライバは、スクロールセンシティブな結果セット、スクロールインセンシティブな結果セット、および更新可能な結果セットをサポートしています。

サーバサイドで更新可能なカーソル

SQL Server ドライバでは、クライアントサイドのカーソルまたはサーバサイドのカーソルを使用して、更新可能な結果セットをサポートすることができます。デフォルトの SQL Server ドライバでは、どのタイプの結果セットでも動作するため、クライアントサイドのカーソルを使用します。通常、サーバサイドのカーソルを使用するとパフォーマンスを向上させることができますが、サーバサイドのカーソルは、スクロールインセンシティブな結果セット、または主キーを含むデータベース テーブルから生成されていないスクロールセンシティブな結果セットで使用することはできません。サーバサイドのカーソルを使用するには、UseServerSideUpdatableCursors プロパティを true に設定します。

UseServerSideUpdatableCursors プロパティを true に設定している場合に、スクロールインセンシティブで更新可能な結果セットが要求されると、ドライバはそのリクエストをスクロールインセンシティブで読み込み専用の結果セットにダウングレードします。同様に、スクロールセンシティブで更新可能な結果セットが要求され、結果セットの生成元のテーブルに主キーが含まれていない場合、ドライバはそのリクエストをスクロールセンシティブで読み込み専用の結果セットにダウングレードします。いずれの場合も警告が生成されます。

サーバサイドで更新可能なカーソルを、主キーを含むデータベースから生成されたセンシティブな結果セットで使用する場合、結果セットに対して行う以下のような変更は参照可能になります。

ドライバのデフォルトの動作を使用すると (UseServerSideUpdatableCursors=false)、変更は参照可能になりません。

JTA 用ストアド プロシージャのインストール

JTA で JDBC 分散トランザクションを使用するには、システム管理者が次の手順に従って、Microsoft SQL Server JDBC XA プロシージャをインストールする必要があります。この手順は、分散トランザクションに関与する MS SQL Server ごとに繰り返す必要があります。

JTA 用ストアド プロシージャをインストールするには

分散トランザクションのクリーンアップ

トランザクションが完了する前にサーバへの接続が失われると、分散トランザクションに関連付けられている接続が孤立する可能性があります。分散トランザクションに関連付けられた接続が孤立すると、そのトランザクションのデータベースによって保持されているロックが維持されるため、データが使用できなくなる可能性があります。分散トランザクションをクリーンアップすると、それらのトランザクションに関連付けられている接続が解放され、データベースによって保持されているロックも解放されます。

XAResource.recover メソッドを使用すると、準備済みでコミットやロールバックはされていない分散トランザクションをクリーンアップできます。このメソッドを呼び出すと、準備済みでコミットやロールバックはされていないアクティブな分散トランザクションのリストが返されます。アプリケーションは XAResource.recover から返されたリストを使用し、それらを明示的にコミットまたはロールバックすることでトランザクションをクリーンアップできます。XAResource.recover によって返されるトランザクションのリストには、アクティブなトランザクションや準備済みでないトランザクションは含まれません。

また、SQL Server ドライバでは、分散トランザクションのクリーンアップに関する以下の方法をサポートしています。

トランザクション タイムアウト

トランザクション タイムアウトのタイムアウト値を設定するには、XAResource.setTransactionTimeout メソッドを使用します。この値を設定すると、サーバ サイドの sqljdbc.dll ではアクティブなトランザクションのリストを保持します。分散トランザクションは、開始されるときにアクティブなトランザクションのリストに配置され、該当する XAResource メソッドを使用して準備、ロールバック、コミット、または無視されるときにこのリストから削除されます。

XAResource.setTransactionTimeout メソッドを使用してトランザクション クリーンアップのタイムアウト値が設定されている場合、sqljdbc.dll はアクティブなトランザクションのリストを定期的に監査して、期限切れのトランザクションがないか調べます。タイムアウト値より有効期間が長いアクティブなトランザクションはロールバックされます。トランザクションのロールバック時に例外が生成された場合は、sqljdbc.dll ファイルと同じディレクトリにある sqljdbc.log ファイルに例外が書き込まれます。

トランザクションのタイムアウト値を小さすぎる値に設定すると、正常に完了していない限りトランザクションがロールバックされてしまう危険性があります。一般的なガイドラインとしては、トラフィックの負荷が大きい状況でもトランザクションが十分完了できる時間にタイムアウト値を設定してください。

値を 0 (デフォルト値) に設定すると、トランザクション タイムアウトのクリーンアップは無効になります。

明示的なトランザクションのクリーンアップ

SQL Server ドライバでは、XATransactionGroup 接続プロパティを使用して、ID をトランザクションのグループに関連付けることができます。トランザクションのグループ ID を指定すると、その接続で開始されたすべての分散トランザクションはこの ID で識別されます。

この値を設定すると、サーバ サイドの sqljdbc.dll ではアクティブなトランザクションのリストを保持します。分散トランザクションは、開始されるときにアクティブなトランザクションのリストに配置され、該当する XAResource メソッドを使用して準備、ロールバック、コミット、または無視されるときにこのリストから削除されます。

XAResource.recover メソッドを使用すると、XAResource.recover を呼び出す際に使用された接続上に、トランザクションのグループ ID が一致し、準備されていない状態のままのトランザクションがあれば、ロールバックすることができます。たとえば、XATransactionGroup=ACCT200 を指定し、同じ接続上で XAResource.recover メソッドを呼び出した場合、トランザクション グループ ID が ACCT200 で、準備されていない状態のままのトランザクションはロールバックされます。

トランザクションのロールバック時に例外が生成された場合は、sqljdbc.dll ファイルと同じディレクトリにある sqljdbc.log ファイルに例外が書き込まれます。

明示的なトランザクションのクリーンアップを使用する場合、孤立した接続に関連付けられている分散トランザクションと、その接続で保持されているロックは、アプリケーションが明示的にクリーンアップを呼び出すまで残されます。一般的なルールとして、アプリケーションは起動時と、サーバへの接続が失われたことを通知された場合に、孤立した接続をクリーンアップする必要があります。

Large Object (LOB) のサポート

Microsoft SQL Server では Blob または Clob データ型は定義されていませんが、SQL Server ドライバによって、Blob および Clob 用に設計された JDBC メソッドを使用して長いデータ (特に LONGVARBINARY データおよび LONGVARCHAR データ) を返したり更新したりできます。これらのメソッドを使用して長いデータを Blob または Clob として更新すると、更新は Blob または Clob オブジェクト内のデータのローカル コピーに対して行われます。

Blob および Clob 用の JDBC メソッドを使用して長いデータを取得および更新すると、Blob および Clob を操作した場合と同じメリットが得られます。たとえば Blob および Clob を使用した場合、

Blob および Clob を使用した場合のこうしたメリットを得るには、データをキャッシュする必要があります。データをキャッシュするので、特に一度にデータの逐次読み出しを行う場合に、パフォーマンスが低下します。長いデータのサイズが使用可能なメモリよりも大きいと、パフォーマンスが著しく低下することがあります。

バッチ挿入とバッチ更新

バッチ挿入およびバッチ更新用の SQL Server ドライバ実装は JDBC 3.0 に準拠しています。SQL Server ドライバは、バッチ挿入またはバッチ更新で文またはパラメータ セットのエラーを検出すると、BatchUpdateException を生成し、残りの文またはパラメータ セットのバッチ処理を続行します。BatchUpdateException 内の更新カウントの配列には、文またはパラメータごとに 1 つのエントリが含まれます。失敗した文またはパラメータ セットのエントリには、Statement.EXECUTE_FAILED 値が含まれます。

パラメータ メタデータのサポート

SQL Server ドライバでは、この節で説明するようにパラメータ メタデータを返すことができます。

Insert 文および Update 文

SQL Server ドライバは、以下の形式の Insert 文および Update 文のパラメータ メタデータを返すことができます。

ここで、operator は SQL 演算子 (=、<、>、<=、>=、または <>) です。

Select 文

SQL Server ドライバでは、ANSI SQL 92 エントリレベルの述語 (比較、BETWEEN、IN、LIKE、EXISTS などの述語構文) にパラメータを含んでいる Select 文に対してパラメータ メタデータを返すことができます。詳細な構文については、ANSI SQL リファレンスを参照してください。

以下のいずれかの条件に該当する場合は、Select 文に対してパラメータ メタデータを返すことができます。

以下の Select 文では、パラメータ メタデータを返すことができる例をさらに示しています。

   SELECT col1, col2 FROM foo WHERE col1 = ? and col2 > ?
   SELECT ... WHERE colname = (SELECT col2 FROM t2  
      WHERE col3 = ?)
   SELECT ... WHERE colname LIKE ?
   SELECT ... WHERE colname BETWEEN ? and ?
   SELECT ... WHERE colname IN (?, ?, ?)
   SELECT ... WHERE EXISTS(SELECT ... FROM T2 WHERE col1 < ?)

GROUP BY、HAVING、または ORDER BY を含む WHERE 句で ANSI SQL 92 エントリレベルの述語を使用する文がサポートされます。次に例を示します。

   SELECT * FROM t1 WHERE col = ?ORDER BY 1

結合がサポートされます。次に例を示します。

   SELECT * FROM t1,t2 WHERE t1.col1 = ?

完全修飾名とエリアスがサポートされます。次に例を示します。

   SELECT a, b, c, d FROM T1 AS A, T2 AS B WHERE A.a = ? and B.b = ?"

ストアド プロシージャ

SQL Server ドライバでは、ストアド プロシージャの引数に対してパラメータ メタデータを返すことはできません。

ResultSet メタデータのサポート

アプリケーションでテーブル名情報が必要な場合、SQL Server ドライバは Select 文の ResultSet メタデータに含めてテーブル名情報を返すことができます。ResultSetMetaDataOptions プロパティを 1 に設定した場合、ResultSetMetaData.getTableName() メソッドが呼び出されたとき、SQL Server ドライバは結果セット内の各カラムの正しいテーブル名を決定する追加の処理を実行します。それ以外の場合、getTableName() メソッドは結果セット内のカラムごとに空の文字列を返す可能性があります。

ResultSetMetaDataOptions プロパティが 1 に設定されていて、ResultSetMetaData.getTableName() メソッドが呼び出された場合、SQL Server ドライバが返すテーブル名情報は、結果セット内のカラムがデータベース テーブル内のカラムにマップされているかどうかによって異なります。結果セット内の各カラムがデータベース テーブル内のカラムにマップされている場合、SQL Server ドライバはそのカラムに関連付けられているテーブル名を返します。結果セット内の各カラムがテーブル内のカラムにマップされていない場合 (集約やリテラルなど)、SQL Server ドライバは空の文字列を返します。

ResultSet メタデータが返される Select 文には、エリアス、結合、および完全修飾名を含めることができます。以下のクエリは、ResultSetMetaData.getTableName() メソッドによって Select リスト内の各カラムの正しいテーブル名が返される、Select 文の例です。

   SELECT id, name FROM Employee
   SELECT E.id, E.name FROM Employee E 
   SELECT E.id, E.name AS EmployeeName FROM Employee E
   SELECT E.id, E.name, I.location, I.phone FROM Employee E, 
      EmployeeInfo I WHERE E.id = I.id
   SELECT id, name, location, phone FROM Employee,
      EmployeeInfo WHERE id = empId
   SELECT Employee.id, Employee.name, EmployeeInfo.location, 
      EmployeeInfo.phone FROM Employee, EmployeeInfo 
      WHERE Employee.id = EmployeeInfo.id

生成されたカラムの場合、ドライバによって返されるテーブル名は空の文字列です。以下のクエリは、生成されたカラム (「upper」という名前のカラム) を含む結果セットを返す Select 文の例です。

   SELECT E.id, E.name as EmployeeName, {fn UCASE(E.name)} 

      AS upper FROM Employee E

SQL Server ドライバは、ResultSetMetaData.getSchemaName() メソッドと ResultSetMetaData.getCatalogName() メソッドが呼び出された場合、スキーマ名とカタログ名の情報を返すこともできます (ドライバがこの情報を判別できる場合)。たとえば、以下の文の場合、SQL Server ドライバはカタログ名として「test」、スキーマ名として「test1」、テーブル名として「foo」を返します。

   SELECT * FROM test.test1.foo 

テーブル名、スキーマ名、およびカタログ名の情報を返すために必要な追加の処理は、ResultSetMetaData.getTableName()、ResultSetMetaData.getSchemaName()、または ResultSetMetaData.getCatalogName() メソッドが呼び出された場合にのみ実行されます。

Rowset のサポート

SQL Server ドライバは、以下のような RowSet インタフェースの JSR 114 実装をサポートします。

ドライバで RowSet を使用するには、J2SE 1.4 以上が必要です。

JSR 114 の詳細については、http://www.jcp.org/en/jsr/detail?id=114 を参照してください。

自動生成キーのサポート

SQL Server ドライバは自動生成キーの値の取得をサポートします。SQL Server ドライバから返される自動生成キーは、identity カラムの値です。

自動生成キーの値を返すことができるのは、アプリケーションで Insert 文を実行するときです。値を返す方法は、パラメータを含む Insert 文を使用しているかどうかによって異なります。

自動生成キーの値は、Statement.getGeneratedKeys() メソッドを使用して取得できます。このメソッドは、各自動生成キーのカラムとともに ResultSet オブジェクトを返します。

Null 値

Microsoft SQL Server ドライバは接続を確立するときに、Microsoft SQL Server のデータベース オプション ansi_nulls を on に設定します。これでドライバが ANSI SQL 標準に準拠するようになり、データベース間を横断するアプリケーションの開発が容易になります。

デフォルトでは、Microsoft SQL Server が SQL の等価比較 (=) または不等価比較 (<>) や集約関数において null 値を評価した場合、ANSI SQL 仕様とは異なる動作となります。たとえば、ANSI SQL 仕様では、以下の Select 文のような col1=null では常に false と評価するよう定義されています。

SELECT * FROM table WHERE col1 = NULL

デフォルトのデータベース設定 (ansi_nulls=off) を使用した同じ比較では、false ではなく true と評価されます。

ansi_nulls を on に設定すると、データベースによる null 値の処理方法が変わり、=NULL ではなく IS NULL の仕様が強制されます。たとえば、以下の Select 文の col1 の値が null である場合、比較の評価は true になります。

SELECT * FROM table WHERE col1 IS NULL

アプリケーションでは以下の方法で、接続に関する Microsoft SQL Server のデフォルトの動作に戻すことができます。

Database 接続プロパティ

Database 接続プロパティは、DatabaseName 接続プロパティのシノニムとして使用できます。

接続 URL に Database と DatabaseName の両方の接続プロパティが指定されている場合は、接続 URL 内で後ろの方に指定されているプロパティが使用されます。たとえば、アプリケーションで次のような URL を指定した場合、DatabaseName 接続プロパティの値ではなく、Database 接続プロパティの値が使用されます。

jdbc:bea:sqlserver://server1:1433;DatabaseName=jdbc;Database=acct;
User=test;Password=secret