問題タブ [hikaricp]

昨日、 HikariCPに出会い、一晩中勉強しました。実装と設計の微調整に費やされた詳細と努力の量に本当に感銘を受けました. 端的に言うと、たとえば、例外が原因で、 にautoCommit設定された状態でプールにチェックインされ、発行も発行もされてfalseいない接続を実際にどのように処理するかを判断できませんでした。これは、新しい接続を期待している次のリクエスタにとって、多くの重大なトランザクションの問題の原因となる可能性がありますが、残念ながら、ダングリング トランザクション状態でこの接続を受け取ります。commit()rollback()

C3P0 と Tomcat の JDBC プールには、まさにこの目的のために (構成またはインターセプトを通じて) いわゆるノブがいくつかありますが、HikariCP のドキュメントまたはサポート グループには何も見つかりませんでした。間違っている場合は訂正してください。ただし、単純な単体テストを作成すると、プールはこれについて何もしないことがわかりました。

この観察が実際に正しいかどうかを知る必要があり、それについて何も見逃していません。また、これは私にとって非常に重要なので、HikariCP でこれに対処する計画があれば。

ありがとう。

私たちのサイトは 1 日あたり約 100 万 pv で、確実に Tomcat を使用しています。

jdbc-poolに関する多くの情報を見つけることができませんでした。本番用に十分に安定しているかどうかはわかりません。経験した人いますか？参照用の構成/チューニングのものはありますか？

誰かが言ったように、BoneCPも別の選択肢かもしれません。でも廃盤のようです（悲しい…）。それはより良い選択でしょうか？

ところで、HikariCPはまだ新しすぎます。私が見つけた最新/最速の CP であるため、今後も注目していきます。

アドバイスをありがとう。

MySQL はサーバー側のクエリ プランのキャッシュをサポートしていないことを読みました。したがって、パフォーマンス上の利点のために PreparedStatements を使用したい場合は、JDBC 接続でステートメント キャッシングを有効にすることができます。したがって、ドキュメントに従って、接続ごとに準備済みステートメントのキャッシュを有効にします。

MySQL にサーバー側のクエリ プラン キャッシュがある場合と比較して、JDBC 接続による PreparedStatement キャッシュのパフォーマンスの向上は何ですか? したがって、PreparedStatement が実際に物理接続のキャッシュで見つかった場合、mysql サーバーに到達したときに、mysql はクエリの最適化を実行せず、直接実行できるということですか?

MySQL をデータベースとして使用している場合でも、JDBC 接続レベルでステートメント キャッシュを使用する必要がありますか? Mysql JDBC コネクタで Hikari データベース接続プールを使用しています。

最近、Spring RESTful API データ ソースを DriverManagerDataSource から HikariCp に切り替えましたが、データベース接続が 20 接続から 600 接続になりました。これは起こると思いますか？

私の設定は次のとおりです。

無効なホスト名またはユーザー/パスワードを使用してこのテストを実行すると、約 2 分間待機してから失敗します。ユーザー/パスワードが正しくない場合、またはホスト名/ポートが正しくない場合は、すぐに失敗することが理想的です。

接続プーリングに MySQL と HikariCP を使用する Web アプリケーションがあります。次のように定義されたシングルトン接続プール オブジェクトを使用してプールに接続します。

私のアプリケーションでは、次のコードを使用してデータ ソースを取得します。

次に、を使用してデータベースに挿入しようとします

しかし、データベースにコミットされた値が表示されません。私は何を間違っていますか？どんな助けでも大歓迎です。