JDBCのパフォーマンス

JDBCのパフォーマンスがあがらず困っています。

LinuxマシンでOracleを稼働しており、そこにJDBCで接続しています。単一でのアクセスでは全く問題のないパフォーマンスですが、同時接続数が2以上になると途端に悪くなります。

# スレッド1→スレッド10でレスポンスに5倍の時間がかかってしまう。。。

OracleでMTS設定なども行ってみましたが、変わりませんでした。コネクションプールも行っています。

JDBCを用いてマルチスレッドでアクセスするときにボトルネックとなるポイント、チェック項目等、アドバイスをいただければ助かります。

よろしくお願いいたします。

[環境]
Linux RedHat6.2J（カーネル2.2.14smp）
Oracle8.1.6
JDK1.3.0
JDBCドライバ　Oracleで配布しているclasses12.zip

No.1 回答者： soakun 回答日時： 2001/10/29 23:21

JDBCの問題か Oracleの問題かを切り離して考える必要が

あるのではないでしょうか。
例えば、アプリケーションプログラム中からSQLを取り出したのち、
SQL*Plusを複数起動してそのSQLを同時に実行した場合との
実行時間をまず比較してみてはどうでしょうか。

この回答への補足

アドバイスありがとうございます。

実行時間の比較の方ですが、JDBCとsqlplusの単一クエリーでの差はそれほどありませんでした。複数同時接続があった場合の比較は行っていません。

# sqlplusで複数同時接続の試験方法が思いつかなかったので。

JDBCで複数同時接続しているときに、sqlplusでクエリーを投げてみましたが、その時のレスポンスは問題ないものでした。

補足日時：2001/10/30 14:38

No.2 回答者： soakun 回答日時： 2001/10/31 00:19

補足していただいた内容を読んだ限り、

SQL自体に問題があるようには見えないようです。

とすると、あとは Oracleへの接続部分か
Javaでのロジックをどうにかすることでしょうか。

念のため確認ですが、INSERT/UPDATE文はがんがん実行されているのでしょうか。その場合、Connectionクラスの setAutoCommitメソッドを実行した覚えはあるのでしょうか。

JDBCのデフォルトでは setAutoCommit(true)、すなわち一行文を実行する毎にコミットがかかります。INSERT/UPDATEがあり、トランザクション的に自動コミットがかかるとまずい場合があるので、まず、setAutoCommit(false); として、更にトランザクションの最後に(明示的に) commitメソッドを実行します。もし問題があれば、rollbackメソッドを使って、トランザクションをキャンセルするようにしましょう。ただし、複数のユーザが同一のConnectionクラスのインスタンスを共有している場合にはこの手法は使えないと思います。

この手の話は Oracleの Oracle8i JDBC Developer's Guide and Reference (Oracle8i JDBC開発者ガイドおよびリファレンス)の第６章 Coding Tips and Trouble Shootingに記述されています。
# 恐らく日本語化されて、紙ベースで存在すると思いますが、手元にあるのが US Oracle/technet のドキュメントしかないため、本当に日本語化されているか確認できません。ごめんなさい(^^;