RDBMS への接続をセットアップしてから、ネットワーク プラグをヤンクすることを検討してください。(接続が NAT ゲートウェイを通過し、ゲートウェイがその接続を消去することを決定した場合も、同じ効果が得られます。)
その時点で、RDBMS サーバーはクエリなどを待機していますが、これは決して発生しません。また、TCP 接続はそのネットワーク上にないため、クライアントによって閉じられることはありません。おそらく、サーバーは接続が開いているとまだ信じているため、サーバーも閉じません。
典型的な RDBMS は、タイムアウトや TCP を介した単純なキープアライブ メカニズムの実装でこれを処理しますか? Oracle、SQL Server、および MySQL でこれを経験したことのある人はいますか?
編集; さらに掘り下げると、mysql は非アクティブ状態が 8 時間続くと接続をパージすることが示唆されます。
それはかなり広い質問です。大雑把な回答をさせてください。
クライアント/サーバーの時代には、クライアントがデータベースへの永続的な接続を維持していたため、これはより大きな問題でした。今日では、スケーラビリティやその他の理由から、アプリケーションは通常、データベースに接続してデータを取得し、すぐに切断する「切断」方式で記述されています。つまり、アプリケーションは必要に応じて接続を要求します。
「アトミック」な操作が発生すると (つまり、操作全体が最初から最後まで正常に完了する必要があります)、その操作はトランザクションにラップされます。トランザクション中にデータベース接続が切断された場合、データベース システムは操作を「ロールバック」し、影響を受けたレコードをトランザクション開始前と同じ状態にします。
タイムアウトにより、データベースへの不要な接続が永久に開かれたままになることがなくなります。
基になる TCP 接続がクライアントまたはサーバーによってドロップされると、反対側の TCP/IP スタックがこれを検出し、アプリケーションに通知します。データベース サーバーが接続を閉じていることを確認できます (コミットされていないトランザクションはすべてロールバックされます)。
更新: ネットワーク障害は、一方が消えたかのように見えるだけです。両側でソケットのタイムアウトを設定し、再試行を行うなどして、これらの障害を適切に処理できるようにします。Jonathan はコメントで興味深いサブイシューを提起し、クライアントがトランザクションを終了せずに明示的に切断した場合、サーバーは暗黙のトランザクション コミットを行うことが判明しました。
あなたが話している特定の状況は実際には起こりません。接続が確立されたからといって、RDBMS がクエリの到着を「待機」しているとは限りません。単に接続の存在に注意し、非同期の読み取り操作を開始してから、自分の仕事を続けます。
非同期読み取りが完了しないことが問題である場合は、もちろん、接続がまだ開いているかどうかを判断する定期的な「ping」メカニズムを RDBMS に実装できます。すでにご存知だと思いますが、TCP/IP 接続は両端で開かれている場合にのみ開かれます。そのため、RDBMS が存在しないクライアントに「ping」を送信すると、書き込みがタイムアウトになり、接続がタイムアウトします。サーバー側が閉じます。RDBMS がそれを認識し、接続に関連付けられているサーバー側のリソースを破棄することが期待されます。
通常、データベース接続はプールされるため、毎回接続を確立するというペナルティを受ける必要はありません。アプリケーション サーバーはこの機能を提供し、通常、この古い接続状態が検出されたときに、接続プールをフラッシュし、プール内のすべての接続を再確立する柔軟性を提供します。
Oracle JDBC ドライバーは、接続クラスで独自の ping() メソッドを提供します。このメソッドは、接続が「アクティブ」であると見なされる場合に true を返します。
残念ながら、ping() は馬鹿によって実装されました。「select 'x' from dual」クエリをサーバーに送信しますが、クエリ キャッシュに苦労を与えるリテラル「x」が存在するため、影響の少ないクエリとはほど遠いものです。
以前は、接続がプールから借用されるたびに、アプリケーション サーバーから ping() を呼び出していましたが、それがオラクル サーバーをほぼ停止させるまで続きました。
推奨されません。
SQL Server では、接続 (sp_who で確認できます) が閉じられ、コミットされていないトランザクションがロールバックされます。
クライアントで見たのは、クライアントからの同じ接続に対する後続の試行 (VPN または NAT が再接続されている場合) は、通常、クライアント側でトランスポート エラーが発生し、新しい接続が同じウィンドウ内の後続のバッチの SSMS の場合。