多数のアクティブな JDBC トランザクションがあり、再デプロイが Web アプリケーションにヒットするとどうなりますか?、Tomcat のドキュメントを検索しましたが、関連するものは見つかりませんでした。
例: 30 人の顧客がアイテムの入ったショッピング カートを持っていて、同時に注文を保存すると、トランザクションが開始され、再デプロイがトリガーされます。すべてのアイテムが正しく保存されますか? または再デプロイ時に、すべてのアクティブなトランザクションが破棄されますか? または Tomcat は、すべてのトランザクションがコミットされるまで redeploy コマンドを待機しますか?
Tomcat JDBC プールを使用しています
覚えておくべき重要なポイントは、接続プールがインスタンス化される場所です。
接続プールをレベルで定義すると、接続Contextプールはコンテキストの作成時に作成され、コンテキストとともに破棄する必要があります。
Tomcat でアプリケーションを再デプロイするには、現在のコンテキストをシャットダウンしてから、代替コンテキストを起動する必要があります。したがって、その場合、各トランザクションdefaultAutCommitの値または実効値によって動作が決定されると予想されます。その後、リソースをシャットダウンすると、トランザクションがコミットされますautoCommit。trueその場合、例外処理パスfalseと同様に、InterruptedExceptionロールバックをトリガーするか、最悪の場合、接続のシャットダウンによってトランザクションがロールバックされます。
本当に調べたいのは、Tomcat がアプリケーションをシャットダウンする方法です。私は実際のコードを詳しく見ていませんが、最初に「古いコンテキスト」へのリクエストの送信を停止することを理解しています。次に、保留中のすべての応答が完了すると、ServletContextListeners が呼び出されてシャットダウンが通知されます。それらとそれに対応する Filter および Servlet が完了すると、コンテキストが効果的にシャットダウンされ、リソースをクリーンアップできます。事態を複雑にしているのは、IIRC は Tomcat が応答が完了するまで待機せず、ハンドラー トレッドの中断を開始したり、古いコンテキストまたはティアダウンが終了するのを待たずに単に新しいコンテキストに切り替えたりする可能性があることです。
どのコンテナー (jetty/tomcat) が新しいコンテキストの起動をサポートしており、新しいコンテキストがゼロ ダウンタイム スイッチ オーバーを提供する準備が整ったときにのみ要求処理を切り替えることをサポートしているかは覚えていません。このような展開モードを使用できるように、クラスタ上で安全に実行できるアプリケーション。
要するに、アプリケーションは新しいコンテキストが開始される前に正常にシャットダウンされるため、トランザクションが完了するか、ブロックが開始さInterruptedExceptionれる時点でレシピが作成されると予想されますtry...finally