ショッピングカートの「買い」を押すなどのウェブショップのシナリオでは、ブラウザのウィンドウやタブを閉じるとどうなりますか？トランザクションが完了する前にユーザーがブラウザのタブを閉じると、データベースセッションはどうなりますか？
は、たとえば問題の製品の数量または応答で発生したデータベーストリガーを更新し、トランザクションの詳細を記録したりロールバックしたり、完了し続けるデータベーストランザクションです。
言い換えれば、停電やインターネット接続が壊れているように、ユーザーがブラウザを喜んで閉じたと判断できる「システム」であり、応答で取引を終了またはキャンセルすることができますか？
実際の環境ではどのように動作しますか？
このような状況で観察できる動作は、データベースだけでなく、Webアプリケーションのアーキテクチャとそのバッキングサービスにも依存します。
このような状況を評価するには、再生中の複数の部分を考慮することが重要です。ブラウザ内のWebアプリケーションを使用する買い物客とバッキングデータベースの間に少なくとも1つ（多くの場合2つ以上） 。
最も単純なケース（ウェブアプリケーションがなく、買い物客がデータベースに直接接続されていると思われる）から始めれば、答えはです。です。 Oracleの内部モニタと接続および切断の責任を負うドライバは、クライアントがコミットされていない変更を解除してロールバックするときを検出するのに非常に優れています。これは、短期間で同じデータ（小売店舗での購入アイテムなど）を更新する必要があるクライアントが多数存在するため、どのような種類のデータベースでも重要な機能です。データの同時アクセスを可能にするデータベースの機能に重大な影響を与えます。これを説明するために例を挙げますが、関連するドキュメントがたくさんあります。概念のマニュアルのProcessesには、関連性の高い多くの情報があります。
私たちにはウェブアプリがなく、SQL Plusなどを介して接続しているだけです。この検出が実際に動作していることがわかります。
はのは、テストテーブルを作成してみましょう：
CREATE TABLE PRODUCT(PRODUCT_ID NUMBER,QUANTITY_REMAINING NUMBER);
Table created.
そして、それにいくつかのレコードを与える：
INSERT INTO PRODUCT VALUES (1,100);
INSERT INTO PRODUCT VALUES (2,1);
COMMIT;
1 row created.
1 row created.
Commit complete.
は、今度は、異なるユーザによって開始された二つのセッションを取得してみましょう。これらの両方のセッションは、アイテム1を購入したいと考えています。Session Aが最初に取得します。
Session A：
UPDATE PRODUCT
SET QUANTITY_REMAINING = QUANTITY_REMAINING - 1
WHERE PRODUCT_ID = 1;
1 row updated.
、予想外にSession A終了する前に、Session Bは、セッションAが行われるまで、彼女は待つ必要があり、製品1を購入しようとします。
Session B：
UPDATE PRODUCT
SET QUANTITY_REMAINING = QUANTITY_REMAINING - 1
WHERE PRODUCT_ID = 1;
お知らせここにいない "1 row updated."。
は、今私がリモートでそれが今など何のコミットまたはロールバックする機会、または正常に終了し、切断、
% kill -9 8771
zsh: killed sqlplus /nolog
Session Aを持っていないSession A（この例ではPID 8771）を殺すことはなくなっていますが、私たちは見ている場合セッションBは、我々はすぐに進めることができました見ることができます：
1 row updated.
そうです、Oracleプロセスの監視は、通常のクライアントが接続を切断するなどの異常なクライアントの切断を処理することができますし、再びokロール。
しかし、それは物語のほんの一部です...一般的なWebアプリケーションでは、Webコンテナによって管理される接続プールに（少なくとも1つの）非常に長寿命の接続があります。データベースには、接続されたクライアントが個々のユーザーか巨大なWebアプリケーションかどうかは関係ありません。予期しない切断も同様に処理されます。
Webアプリケーションでは、Webアプリケーションのデータベース接続を制御しません。ユーザーはブラウザを介してWebアプリケーションとやりとりし、そのWebアプリケーションと通信している別のサービスアプリケーションデータベース。ブラウザのユーザーは、どのようなデータが更新されているか、どのようにしてショッピングカートに何かを入れたいのか分かりません。 Webアプリケーションがデータベース接続を使用して実行する操作を制御することはできません。
これらの追加の部分を再生すると、その答えはアプリケーションのアーキテクチャとデザイン（データベースではありません）によって異なります。ユーザーが買い物カゴに何かを入れる（または注文を完了する）というリクエストを送信した後で、応答を返す前に予期せず接続が切断された場合でも、そのリクエストはサーバーによって完了しますが、 "ok"応答を返す。
アプリケーション開発者（またはWebフレームワーク）は、不足している買い物客を無期限に待っている可能性のあるカート内アイテム（データベースに既に正常に保存されているアイテム）をどうするかを決定します。
多くのアプリケーション開発者（およびWebフレームワーク）は、クライアントが要求の状態を明確に把握するのに役立つ手段を用意しています（たとえば、ポップアップがタブまたはブラウザの終了を妨げますか？不完全な順序？」など）。ショッピングカートに入っていて、しばらくして購入していないものを「ロールバック」するためのモニタを構築するか、購入が実際に完了したときに確認する電子メールを送信する（「購入」をクリックした直後に電源が切れた場合"）などですが、それはアプリケーション開発者が決定するものです。
要約すると、はいOracleデータベースは、クライアントの停電などのイベントで不完全なトランザクションを検出して、うまくロールバックできます。 Webアプリケーションでは、異なる時間に行方不明になるクライアントのさまざまなニーズを満たし、理解可能で満足できるユーザーエクスペリエンスを提供するために、さまざまなデザインと技術があります。