JDBC のログ
アプリケーションで問題が発生した場合、ログを有効にしてアプリケーションを監視できます。アプリケーションを実行し、エラー条件をトリガしたことを確認した後、エラー・メッセージや、異常な活動のすべてのログ記録をチェックします。エラーの原因は通常、メッセージ内に表れています。
Note:
ログは、トラブルシューティングを実行する必要がある場合のみ有効にします。ログを有効にするとパフォーマンスが大幅に低下するため、通常の操作時は有効にしないでください。
InterSystems IRIS に接続するときに JDBC のログを有効にするには、JDBC 接続文字列の末尾にログ・ファイル名を追加します。接続時に、ドライバによってアプリケーションの作業ディレクトリに保存されるログ・ファイルが保存されます。
例えば、元の接続文字列が以下であるとします。
jdbc:IRIS://127.0.0.1:1972/USER
ログを有効にするには、この文字列を以下のように変更して再接続します。
jdbc:IRIS://127.0.0.1:1972/USER/myjdbc.log
このログには、InterSystems IRIS データベースから見た対話処理が記録されます。
指定されたログ・ファイルが存在する場合、既定では新しいログ・エントリがそのファイルに追加されます。既存のファイルを削除して、新しいファイルを作成するには、接頭語としてログ・ファイル名の前にプラス (+) 文字を付けます。例えば、次の文字列では、myjdbc.log を削除し (既存の場合)、同じ名前で新しいログ・ファイルを作成します。
jdbc:IRIS://127.0.0.1:1972/USER/+myjdbc.log
共有メモリ接続
InterSystems IRIS では、Java アプリケーションが InterSystems IRIS サーバ・インスタンスと同じマシン上で実行されている場合、TCP/IP ではなく共有メモリ接続が使用されます。このセクションでは、共有メモリが動作するしくみと、開発およびテストの目的で共有メモリを無効にする方法について説明します。
共有メモリ接続は、高いコストのかかる可能性があるカーネル・ネットワーク・スタックの呼び出しを回避して、JDBC 操作のために最適な低遅延と高スループットを実現することで、パフォーマンスを最大化します。
接続でサーバ・アドレス localhost または 127.0.0.1 が指定されている場合、既定で共有メモリが使用されます。実際のマシン・アドレスが指定されている場合は、TCP/IP が使用されます。共有メモリ・デバイスに障害が発生した場合、または共有メモリ・デバイスが利用できない場合、接続は自動的に TCP/IP にフォールバックします。
共有メモリを無効にするには、接続文字列で SharedMemory プロパティを false に設定します。以下の例では、サーバ・アドレスが 127.0.0.1 に指定されている場合でも共有メモリを使用しない接続を作成します。
Properties props = new Properties();
props.setProperty("SharedMemory", "false");
props.setProperty("user", "_system");
props.setProperty("password", "SYS");
IRISConnection conn = (IRISConnection)DriverManager.getConnection("jdbc:IRIS://127.0.0.1:1972/USER/ ",props);
アクセサ DataSource.getSharedMemory() および DataSource.setSharedMemory() を使用して、現在の接続モードの読み取りおよび設定を行うことができます。IRISConnection.isUsingSharedMemory() メソッドを使用して、接続モードをテストすることもできます。
共有メモリは TLS または Kerberos 接続には使用されません。共有メモリ接続が試行されたかどうか、およびその接続が成功したかどうかの情報は、JDBC ログに記録されます (“JDBC のログ” を参照してください)。
Note:
共有メモリ接続はコンテナの境界を越えて機能しない
現在のところ、2 つの異なるコンテナ間の共有メモリ接続はサポートされていません。クライアントが localhost または 127.0.0.1 を使用してコンテナの境界を越えて接続を試行した場合、接続モードは既定で共有メモリになり、接続は失敗します。このことは、Docker の --network host オプションが指定されているかどうかに関係なく適用されます。サーバ・アドレスの実際のホスト名を指定するか、接続文字列で共有メモリを無効にすることで (上記の例のように)、コンテナ間の TCP/IP 接続を保証できます。
サーバとクライアントが同じコンテナにある場合は、問題なく共有メモリ接続を使用できます。
文のプーリング
JDBC 4.0 は、追加のインフラストラクチャである「文のプーリング」を追加しています。この機能により、最適化された文は、最初に使用されたときにキャッシュに格納されます。文のプールは、接続プールによって維持され、プールされた文を接続間で共有できます。実装の詳細は、ユーザに対して完全に透過的です。必要な機能を提供するかどうかはドライバで決まります。
InterSystems JDBC は、この概念が JDBC 仕様の一部になるかなり前から文のプーリングを実装していました。一方、InterSystems IRIS ドライバは、この仕様で推奨されているテクニックに類似したテクニックを使用しており、実際にプーリングを実装すると高度に最適化されます。ほとんどの実装と異なり、InterSystems JDBC は、3 つの別々の文プーリング・キャッシュを備えています。1 つは JDBC 仕様で定義されている文プーリングにほぼ相当しますが、その他の 2 つは InterSystems IRIS 特有の最適化です。必要に応じて、InterSystems JDBC 文プーリングは、ユーザに対して完全に透過的になります。
InterSystems JDBC の実装は、Statement メソッドである setPoolable() および isPoolable() を、当該の文をプールする必要があるかどうかのヒントとしてサポートします。InterSystems IRIS は、独自のヒューリスティックを使用して、3 つの文プールすべての適切なサイズを決定します。したがって、IRISConnectionPoolDataSource の maxStatements プロパティを設定することによる文プール・サイズの制約をサポートしません。オプションの javax.sql.StatementEventListener インタフェースは同じ理由でサポートされません (また、重要ではありません)。