問題タブ [transactionscope]

助けが必要です。まず、小さなサンプルでシナリオを説明しましょう。

列のあるStudentsテーブルがあるとします。

このテーブルには膨大な数のレコードがあります。

次に、各学生のTotalMarksを計算して、TotalMarks列を更新します。

C＃コンソールアプリに来て、ストアドプロシージャを呼び出しています。

SP1 => InProcess=0およびIsTotalCalculated=0の上位2つのレコードを一度にフェッチし、そのInProcess = 1を設定して、処理を実行します。（SELECTとUPDATEがあります）

SP2 =>最後に、IsTotalCalculated=1およびInProcess=0を更新するこれらの2つの行を再度更新します（UPDATE）

懸念事項：私の懸念は、処理する2つの行を選択するとすぐに、他のコンソールアプリインスタンスがこれらの2つの行を処理対象として選択しないようにすることです。私は何をすべきか？
注：2つのSPのC＃コードをTransactionBlockに配置しました。

ありがとう、

ジャスティン・サミュエル

このようなものがある場合：

内側の TransactionScope scope2 もロールバックされますか?

おそらくMSDTCに関連する、ローカルなものであることがわかっている問題があります（私はそれについてあまり知りません）。

他のプロジェクト開発者 (同じコードベース、コミットされたすべて) がソリューション全体を実行しますが、データベースからデータを取得しようとすると (常にではありません)、次のエラーが発生します。

using transaction スコープ、complete() などすべてをコメントすると、期待どおりに動作します。

以前にこの問題が発生したことがありますか?

編集：

このエラーをスローするクエリは、次のような非常に単純なものです。

編集、解決済み：

サーバーの lmhosts が古くなっています。

(DTC を取り巻く状況と取引の促進は、知らない人にとっては少し不可思議なことかもしれませんが、私の会社がどのように物事を行っているかをお見せしましょう。また、DTC が関与している理由を教えていただければ幸いです。 、可能であれば、それを回避するために何ができるか、感謝します.)

ASP.Net Web サーバーでコードを実行しています。データベースは 1 つ、SQL 2008 です。

データ アクセス コードは次のようになります。SQLConnections と SQLCommands のラッパー オブジェクトを使用するデータ アクセス層があります。典型的な使用法は次のようになります。

実際、SqlClient、SqlConnection などの非常に薄いラッパーです。トランザクションでいくつかのストアド プロシージャを実行したいのですが、ラッパー クラスでは SqlTransaction にアクセスできないため、あるコンポーネントから次のコンポーネントに渡すことができません。 . これにより、TransactionScope を使用するようになりました。

これを行うと、DTC が関与します。残念ながら、私たちの Web サーバーでは、MSDTC 設定で「リモート クライアントを許可する」が有効になっていません。

DTC の関与を避けたいのですが、できますか? Methods1-3() のトランザクション呼び出しを省略して、TransactionScope にすべてを理解させることはできますか?

CN1 という sqlconnection を作成しました。次に、この CN1 を開きます。コードの後半に transactionscope があります。この CN1 接続で SQL コマンドを実行すると、これはトランザクション内ですか?

コードは次のようになります。

次のことを行うための最良の方法を知る必要があります。ビジネス レベルの API (レベル 1 とレベル 2 など) をネストしています。L1 は L2 を呼び出す必要があります。どちらの API も、独自のネスト レベルでデータベース レイヤーを直接使用します。

ここで、データベース層で、次のように毎回プールから db 接続をフェッチします。

1. 上記のように、DBレベルの呼び出しごとに毎回db接続を取得するのは適切ですか? ASP.NET 接続プールから接続が返されることはわかっています。

2. ただし、ネストされた呼び出し全体 (または現在の http 要求の有効期間全体) で同じ DB 接続を維持する方がよいのではないでしょうか?

3. 毎回プールから接続をフェッチすると、ネストされた TransactionScopes で問題が発生しますか?

TransactionScope は、次のように Complete メソッドの呼び出しを想定しています。そうしないと、トランザクションはコミットされません。

成功を前提とした実装の方が適切ではないでしょうか? これは、標準的なケース (成功) で必要なコードが少なくなることを意味します。

例外または「Rollback」などのメソッドへの呼び出し (このメソッドは現在存在しません) の場合、トランザクションはロールバックされる可能性があります。

problemOccurred フラグは、問題が例外にならなかった場合にのみ必要になることに注意してください。この場合、ロールバックは自動的に実行されます。

この実装が使用された理由についてさらに洞察を得ることに興味があります。

更新:これまでの回答のいくつかは、私が説明した実装が使用された場合、try-catch ブロックが必要になると主張していました。これはそうではありません。using ブロック内で例外が処理されない場合、トランザクションは自動的にロールバックされます。これは、既存の実装と私が説明した実装の両方に当てはまります。詳細については、こちらの「トランザクション スコープの完了」セクションを参照してください。

更新 2:回答で説明されていたことをようやく理解しました。これは、言語設計者が適切と考える方法で解釈できる言語構成ではなく、IDisposable パターンの実装です。Complete への呼び出しがなければ、Dispose メソッド内のコードは、using ブロック内のコードが正常に実行された結果として呼び出されたのか、それとも例外が発生したために呼び出されたのかを認識できません。transaction と rollback の両方がキーワードである次のようなものを想像していました。

これはもちろん、トランザクション オプションを TransactionScope に渡す必要がある場合に問題を引き起こします。

C＃のトランザクションスコープには、設計による選択SQLクエリ（select * from table1 eg）があります。通常、アンビエントトランザクションがありますが、このSQLクエリを実行するときにアンビエントトランザクションを抑制すると、パフォーマンスが向上しますか？

EntityFrameworkを使用するWebアプリケーションがあります。TransactionScopeクラスを使用してアンビエントトランザクションを提供します。

DTCトランザクションよりも標準のT-SQLトランザクションを使用するようにEFに指示する方法はありますか？1つのEntityContextと1つのTransactionScopeインスタンス内のさまざまなテーブルに対して多くのクエリを実行することがよくありますが、これは常にトランザクションをDTCにプロモートするようです。

簡単な例をまとめました。以下を参照してください。個々のテーブルへのクエリはT-SQLトランザクションを正しく開始し、接続SPID 54にありました次にContactUsテーブルへのクエリが行われ、EFはトランザクションを促進する効果がある別の接続（SPID 53）でこれを行いますDTCトランザクションに。**

TransactionScope親の中に子供がいますTransactionSope。子TransactionScopeは、単一の親の下で複数回作成、実行、およびコミットされTransactionScopeます。

親TransactionScopeはInsert、挿入ステートメントの2番目のセットが1つずつ実行を完了するのを待っている間、データベースへの単一のレコードを処理します。

最初のトランザクションを完了した後、子トランザクションの最初の挿入時に問題が発生しました。昨日からたくさんの調査を行った結果、2番目の挿入が実行されているプロセスが最初の挿入のプロセスによってブロックされていることがわかりました。

SP_WHO2プログラムが実行されている状態でSQLServerで実行すると、これがわかりました。

一方、挿入プロセスに関与する2つのテーブルの間には1対多の関係があります。最初の挿入は親テーブルで操作を実行し、2番目の挿入は子テーブルで実行されます。

2つのテーブル間の関係制約を削除すると、トランザクションは実行されますが、制約がオンの場合は削除されません。

私の質問は、最初の挿入によってブロックされている2番目のプロセスのブロックを解除する方法です。