0


0

RDBMSへの接続を設定し、次にネットワークプラグをヤンクすることを検討してください。 (接続がNATゲートウェイを通過し、ゲートウェイがその接続を削除することにした場合も、同じ効果が得られます。)

その時点では、RDBMSサーバーはクエリーを待っています。 TCP接続は、そのネットワーク上に存在しないため、クライアントによって閉じられることはありません。 おそらく、サーバーは接続がオープンされているとまだ信じているので、サーバーはそれをクローズしません。

典型的なRDBMSはこれをタイムアウトやTCP上での単純なキープアライブメカニズムの実装で処理しますか? Oracle、SQL Server、MySQLについてこれを使用した経験がある人はいますか

編集します。さらに掘り下げてみると、mysqlは8時間の非アクティブの後に接続を削除することを示唆しています。

6 Answer


1


かなり広い質問です。 私はあなたに広い答えをさせてください。

クライアント/サーバーの時代には、クライアントはデータベースへの持続的な接続を維持していたので、これはもっと大きな問題になっていました。 今日では、スケーラビリティやその他の理由から、アプリケーションは一般に「切断」方式で記述されているため、データベースに接続してデータを取得し、その後すぐに切断されます。 つまり、アプリケーションは必要に応じて接続を要求します。

操作が発生したとき、それは「アトミック」です。 操作全体が最初から最後まで正常に完了する必要があります。その操作はトランザクションにラップされます。 トランザクション中にデータベース接続が切断されると、データベースシステムは操作を「ロールバック」し、影響を受けるレコードをトランザクション開始前と同じ状態にします。

タイムアウトは、データベースへの漂遊した接続が永遠に開かれたままにならないことを保証します。


1


基礎となるTCP接続がクライアントまたはサーバーによってドロップされると、反対側のTCP / IPスタックがこれを検出してアプリケーションに通知します。 データベースサーバが接続を確実に閉じる(そしてコミットされていないトランザクションをロールバックする)ことを確認できます。

更新:ネットワーク障害は、相手が去ったようにそれぞれの側に見えます。 双方はソケットのタイムアウトを設定したり、再試行したりします。 そう彼らはこれらの失敗を優雅に扱うことができました。 Jonathanはコメントで興味深い副次問題を提起し、クライアントがどちらの方法でもトランザクションを終了せずに明示的に切断した場合、サーバーは暗黙のトランザクションコミットを行うことがわかりました。


0


あなたが話している特定の状況は実際には起こりません。 接続が確立されたからといって、RDBMSがクエリーの到着を「待っている」ことを意味するわけではありません。 単に接続の存在を確認し、非同期の読み取り操作を開始してから、そのビジネスについて続行することができます。

非同期読み取りが完了しないようにすることが問題であれば、もちろん、RDBMSは接続がまだ開いているかどうかを判断する定期的な「ping」メカニズムを実装することができます。 ご存じのとおり、TCP / IP接続は両端で開いている場合にのみ開いているので、RDBMSがもう存在しないクライアントに「ping」を送信した場合、書き込みは接続をタイムアウトしますサーバー側は閉じます。 RDBMSがそれに気付き、接続に関連したサーバー側のリソースを破壊することを期待するでしょう。


0


データベース接続は通常プールされているので、毎回接続を確立することによる不利益を被る必要はありません。 アプリケーションサーバはこの機能を提供し、通常、この古い接続状態が検出されたときに接続プールをフラッシュし、プール内のすべての接続を再確立する柔軟性を提供します。


0


Oracle JDBCドライバは、接続クラスに対してproprietery ping()メソッドを提供します。このメソッドは、接続が「アクティブ」と見なされるとtrueを返します。

残念ながら、ping()はばかげて実装されました。 これは、「xから二重に選択」クエリをサーバーに送信しますが、クエリキャッシュに苦労する文字「x」が存在するため、影響の少ないクエリにはほど遠いです。

接続がプールから借用されるたびに、私たちのアプリケーションサーバーからping()を呼び出すのが常でした。これは、Oracleサーバーがほとんど停止するまでです。

お勧めしません。


0


SQL Serverでは、接続(sp_whoで確認できます)は閉じられ、コミットされていないトランザクションはロールバックされます。

私がクライアント上で見たことは、クライアントからの同じ接続での後続の試み(VPNまたはNATが再接続されている場合)は通常クライアント側でトランスポートエラーを引き起こし、新しい接続がクライアント側で作成されるということです。同じウィンドウ内の後続のバッチに対するSSMSの場合。