|
|
Administration Console、JMX プログラム、または WebLogic Scripting Tool (WLST) スクリプトを使用して、ドメイン内の JDBC データ ソースを管理できます。この節の内容は、以下のとおりです。
データ ソース内のデータベース接続が正常な状態であることを確認するには、接続を定期的にテストする必要があります。WebLogic Server では、2 種類の基本的なテストが行われます。データ ソース上で属性を使ってコンフィグレーションする自動テストと、データ ソースのトラブルシューティングに利用できる手動テストです。
WebLogic Server がプール接続の一貫性を自動的に保てるようにすることで、DBMS 接続に関する問題の大半は防げるはずです。自動接続テストのコンフィグレーションの詳細については、「データソースの接続テスト オプション」を参照してください。
データ ソースからの接続の手動テストには、Administration Console の [JDBC データ ソース : モニタ : テスト] ページの [データ ソースのテスト] 機能 (「JDBC データ ソースのテスト」を参照) または JDBCDataSourceRuntimMBean の testPool() メソッドを使用できます。データ ソースからのデータベース接続をテストするには、データ ソースのコンフィグレーションで [予約時に接続をテスト] を有効化し、[テスト対象のテーブル名] を定義しておく必要があります。どちらも、Administration Console を使用してデータ ソースを作成した場合には、デフォルトで定義されます。
データ ソースをテストする際、WebLogic Server は接続を予約し、[テスト対象のテーブル名] で定義したクエリを使用してそれをテストし、その後、接続を解放します。
システム内のデータ ソースにおける各接続について、WebLogic Server はステートメント キャッシュを作成します。接続でプリペアド ステートメントまたは呼び出し可能ステートメントが使用されると、WebLogic Server はその文をキャッシュして、再利用できるようにします。ステートメント キャッシュの詳細については、「ステートメント キャッシュによるパフォーマンスの向上」を参照してください。
データ ソースの各接続には、独自のステートメント キャッシュがありますが、コンフィグレーションの設定はデータ ソース内のすべての接続に対して行われます。Administration Console を使用して、データ ソース内のすべての接続についてステートメント キャッシュをクリアすることも、プログラムを介して個々の接続についてステートメント キャッシュをクリアすることもできます。
データ ソース内のすべての接続についてステートメント キャッシュを手動でクリアするには、Administration Console を使用する (「
JDBC データ ソース内のステートメント キャッシュのクリア」を参照) か、または JDBCDataSourceRuntimeMBean の clearStatementCache() メソッドを使用します。
weblogic.jdbc.extensions.WLConnection.clearStatementCache()
weblogic.jdbc.extensions.WLConnection.clearCallableStatement(java.lang.
String sql)
weblogic.jdbc.extensions.WLConnection.clearCallableStatement(java.lang.
String sql,int resType,int resConcurrency)
weblogic.jdbc.extensions.WLConnection.clearPreparedStatement(java.lang.
String sql)
weblogic.jdbc.extensions.WLConnection.clearPreparedStatement(java.lang.
String sql,int resType,int resConcurrency)
weblogic.jdbc.extensions.WLConnection インタフェースのメソッドを使用すると、単一の接続用のステートメント キャッシュをクリアするか、キャッシュから個別に文をクリアできます。これらのメソッドは、処理が正常に実行されると true を返し、文が見つからなかったために処理が失敗すると false を返します。
プリペアド ステートメントと呼び出し可能ステートメントがキャッシュに格納される場合、これらは正確な SQL 文と、必要に応じて結果セット パラメータ (タイプおよび同時実行性オプション) に基づいて格納 (キー化) されます。個々のプリペアド ステートメントまたは呼び出し可能ステートメントをクリアする場合は、適切な結果セット パラメータを取るメソッドを使用する必要があります。たとえば、resSetType が ResultSet.TYPE_SCROLL_INSENSITIVE で resSetConcurrency が ResultSet.CONCUR_READ_ONLY のキャッシュ内に呼び出し可能ステートメントがある場合は、結果セット パラメータを取るメソッドを使用することが必要です。
clearCallableStatement(java.lang.String sql,int resSetType,int resSetConcurrency)
パラメータとして SQL 文字列のみを取るメソッドを使用する場合は、メソッドは文を見つけられず、キャッシュからクリアされるものはありません。メソッドは false を返します。
現在アプリケーションによって使用中の文をクリアする場合、WebLogic Server はその文をキャッシュから削除しますが、閉じはしません。現在使用中でない文をクリアする場合、WebLogic Server はキャッシュからその文を削除して閉じます。
これらのメソッドの詳細については、WLConnection の Javadoc を参照してください。
データ ソースは、プール内の接続の初期数と最大数を定義する一連のプロパティ (initialCapacity と maxCapacity) と、接続がすべて使用中のときにプールに追加される接続の数を定義するプロパティ (capacityIncrement) を備えています。プールがその最大容量に達すると、最大数の接続が開くことになり、データ ソースで自動縮小を有効化するか、shrink() メソッドを使って手動でデータ ソースを縮小しない限り、それらの接続は開いたままになります。
接続の使用がピークを過ぎれば、データ ソースから接続をいくつか削除して、WebLogic Server と DBMS のリソースを解放してもかまいません。Administration Console の [JDBC データ ソース : 制御] ページの [縮小] オプション (「JDBC データ ソース内の接続プールの縮小」を参照)、または JDBCDataSourceRuntimeMBean の shrink() メソッドを使用できます。データ ソースを縮小するとき、WebLogic Server はプール内の接続の数を、初期容量と現在使用中の接続数の、いずれか大きいほうの数まで低減します。
データ ソースの利用可能なすべてのデータベース接続を閉じて再作成するには、Administration Console の [
JDBC データ ソース : 制御] ページの [リセット] オプション (「
JDBC データ ソース内の接続のリセット」を参照)、または JDBCDataSourceRuntimeMBean の reset() メソッドを使用できます。これは、たとえば、DBMS が再起動された後に必要になることがあります。データ ソース内の 1 つの接続が失敗した場合は、プール内のすべての接続が不良であることが往々にしてあります。
データ ソースを中断するには、Administration Console の [
JDBC データ ソース : 制御] ページの [中断] オプションと [強制中断] オプション (「
JDBC データ ソースの中断」を参照)、または JDBCDataSourceRuntimeMBean の suspend() メソッドと forceSuspend() メソッドを使用できます。
データ ソースを中断 (強制中断ではない) する場合、データ ソースは無効化されたものとしてマークされ、アプリケーションではプールからの接続を使用できません。中断されたデータ ソースからの接続をすでに予約していたアプリケーションは、その接続を使用しようとしたときに例外を受け取ります。データ ソース内のすべての接続は、データ ソースが中断される前の状態のままで保持されます。
データ ソースを強制中断する場合、WebLogic Server はデータ ソースを無効化されたものとしてマークし、現在接続を使用中のアプリケーションの接続を強制的に解除し、データ ソースが中断された時点で使用中だった接続を再作成します (閉じてから再び開きます)。閉じられる接続上のトランザクションはすべてロールバックされます。WebLogic Server は、他の接続をすべて、データ ソースが中断される前の状態のままで保持します。
中断したデータ ソースを再有効化するには、Administration Console の [
JDBC データ ソース : 制御] ページの [再開] オプション (「
中断されている JDBC データ ソースの再開」を参照)、または JDBCDataSourceRuntimeMBean の resume() メソッドを使用できます。データ ソースを再開する場合、WebLogic Server はデータ ソースを有効化されているものとしてマークし、アプリケーションでデータ ソースからの接続が使用できるようにします。データ ソースを中断 (強制中断ではない) した場合、すべての接続が、中断前とまったく同じ状態で保存されます。データ ソースの中断前に接続を予約してあったクライアントは、中断した箇所とまったく同じところから JDBC 処理を続行できます。データ ソースを強制中断した場合、中断の時点で使用中ではなかった接続が、中断前とまったく同じ状態で保存されます。使用中だった接続は、閉じられ、再び開かれます。接続を予約してあったクライアントには、有効な JDBC コンテキストがなくなっています。
| 注意 : | たとえばデータベース サーバが利用できない場合などの、正しく起動しなかったデータ ソースは再開できません。 |
データ ソースを停止するには、Administration Console の [
JDBC データ ソース : 制御] ページの [停止] オプションと [強制停止] オプション (「
JDBC データ ソースの停止」を参照)、または JDBCDataSourceRuntimeMBean の shutdown() メソッドと forceShutdown() メソッドを使用できます。
データ ソースを停止する (強制停止ではない) 場合、WebLogic Server はデータ ソース内のデータベース接続を閉じ、データ ソースを停止します。データ ソースのいずれかの接続が使用中の場合、このオペレーションは失敗します。
データ ソースを強制停止する場合、WebLogic Server はデータ ソース内のデータベース接続を閉じ、データ ソースを停止します。現在の接続ユーザはすべて強制的に接続解除されます。
データ ソースを停止後、Administration Console の [
JDBC データ ソース : 制御] ページの [起動] オプション (「
JDBC データ ソースの起動」を参照)、または JDBCDataSourceRuntimeMBean の start() メソッドを使用できます。起動処理を呼び出すと、データ ソースが再初期化され、接続が作成され、データ ソースが [実行中] 状態に遷移します。
  
|
