テーブルアダプタを使用したトランザクションに関するこのすばらしい記事を見つけました。ただし、この記事では、トランザクションが必要な理由、または望ましい理由については説明していません。
TableAdaptersと一緒にトランザクションを実装しようとする価値があるのはなぜですか?
テーブルアダプタを使用したトランザクションに関するこのすばらしい記事を見つけました。ただし、この記事では、トランザクションが必要な理由、または望ましい理由については説明していません。
TableAdaptersと一緒にトランザクションを実装しようとする価値があるのはなぜですか?
データベースに複数のクエリを実行するものを保存している最中に、何か悪いことが起こったとします。保存操作を開始したときにすでに保存されているすべてのデータをどうしますか?ほとんどの開発者は、以前に保存されたデータを無効にしたいと考えています。それがトランザクションの目的です。トランザクションにすべての保存ロジックをカプセル化して、途中で何か問題が発生した場合に何も保存されないようにします。
トランザクションの件名の詳細:http://en.wikipedia.org/wiki/Database_transaction
「理由」は、これらのデータベース操作をより広いトランザクションユニットの一部として実行することです。これにより、アトミック(オールオアナッシング)な方法でデータベース操作をコミットしたり、読み取りと書き込みを確実に実行したりできます。同じトランザクション(ファントム/繰り返し不可能な読み取りを回避するため)。実は私はアダプターモデルの大ファンではありませんが...
方法については; TransactionScope
ADO.NET接続は自動登録する必要があるため、より簡単になります。
using(var tran = new TransactionScope()) {
// do work A
// do work B
// do work C
tran.Complete();
}
仕事は終わりました...
アトミック呼び出しで保証された更新が必要な複数のテーブルがあるsituatinoがある場合、トランザクションによってこれが可能になります。トランザクションがないと、1つのテーブルを更新できる可能性があり、2つ目は失敗し、問題のあるデータが残ります。たとえば、yuoに1つの画面があり、ボタンを1回クリックするだけで親レコードと子レコードの束を追加したい場合があります。トランザクションがない場合、親は正常に保存しますが、子レコードの1つが爆発します。トランザクションでは、すべてをロールバックし、データの問題を修正するようにユーザーに依頼します。
トランザクションを使用すると、データベース内のデータの整合性を維持できます。通常、すべてのデータベースの更新/挿入にトランザクションを導入することをお勧めします。指定されたストアドプロシージャが何らかの理由で失敗した場合は、常にロールバックします。
皆さんがここに投稿したすべてのことは私には良いことのように聞こえますが、ソリューションに対しては常に長所と短所があることを忘れてはなりません。たとえば、アプリケーション側でトランザクションを管理すると(方法は関係ありません)、 .netはすべてのコマンドをSQLServerに送信する必要があるため、ネットワークトラフィック:
using(var tran = new TransactionScope()){
// do work A
// do work B
// do work C
tran.Complete();
}
この場合、「トランザクションの開始」と「コミット」を送信する必要があります。
起こりうる最悪の考えは、「// do work b」の後で接続が切断された場合、どうなるかということです。これは、.Netが「ロールバック」または「コミット」のどちらも送信できないことを意味します。そのため、SQL Server側でトランザクションが開かれ、デッドロックが発生する可能性があります。