1

プログラムで MaxOpenPreparedStatement 例外が発生します。getNumActive()/getNumIdle() 関数を使用して、GenericObjectPool 内のオブジェクトの数を監視できます。org.apache.commons.dbcp.BasicDataSource オブジェクトから接続と準備済みステートメント プールを取得するにはどうすればよいですか? ありがとう

4

3 に答える 3

2

実際の質問に対する答えはわかりませんが、準備済みステートメントの最大許容量は通常かなり高いです。したがって、この質問をする原因となった技術的な問題はfinally、次の JDBC イディオムに従って、JDBC コードがブロック内の開かれたすべてのステートメントを適切に閉じていないことであると強く思います。

Connection connection = null;
PreparedStatement preparedStatement = null;
ResultSet resultSet = null;
// ...

try {
    connection = database.getConnection();
    preparedStatement = connection.prepareStatement(SQL_STRING);
    resultSet = preparedStatement.executeQuery();
    // ...
} finally {
    if (resultSet != null) try { resultSet.close(); } catch (SQLException ignore) {}
    if (preparedStatement != null) try { preparedStatement.close(); } catch (SQLException ignore) {}
    if (connection != null) try { connection.close(); } catch (SQLException ignore) {}
}
于 2010-07-01T21:31:34.327 に答える
0

DBCP の BasicDataSource は、データソースが構成されているmaxOpenPreparedStatements値を公開します。

この例外の存在は、開いているステートメントが多すぎて閉じていないことを示しているようです。

通常、接続では一度に 1 つまたは 2 つのステートメントしか使用されないため、これは主にリソース リークの検出に役立ちます。

于 2010-07-01T13:50:09.040 に答える
0

BasicDataSource をサブクラス化し、createPoolableConnectionFactory をオーバーライドして、ステートメント プール ファクトリを自分で作成したものに置き換える (したがって追跡できる) ことで、DBCP の内部構造を把握できる場合があります。

ここでの他の回答と同様に、これは準備済みステートメントが開いたままになっていることを示しているようです。元の問題をデバッグしやすくします。

于 2011-02-16T23:05:32.023 に答える