Entity FrameworkおよびWCFをトランザクションと連携させるにはどうすればよいですか？さて、秘密は何ですか？

Question

私はシンプルなWCFクライアント/サーバーの状況で動作する単純なトランザクションセットを得るためにいくつかの方法を試してきました。私のWCFサーバーには、データベースアクセスのためのEntity Frameworkクラスのクラスレベル宣言と、SaveChangesへのデータとメソッドを変更するいくつかのメソッドがあります。 Oracle Data Access（ODP.NET）を使用しています。

たとえば、クライアントからの変更を呼び出してから、WCFサービスの変更を保存する別の呼び出しを呼び出したいとします。それは動作しません。基本的にはすべて正常に実行されますが、変更を保存するための2回目の呼び出しが行われると、WCFサービスはもはや元のコンテキストを持たないため、変更は保存されません（したがって、変更を加えた前の呼び出しは自動的にロールバックされます） 。

私はクライアントで両方の操作の周りにTransactionスコープを利用していますし、完了後にComplete（）を実行しています。私のWCFサービスは、[TransactionFlow(TransactionFlowOption.Mandatory)]を使用するOperationContractを持ち、これらのメソッドの実装は[OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = true)]を使用します。最後に、私のWeb設定は、transactionFlowプロパティがTrueに設定されているwsHttpBindingで設定されています。

私は運がありません。私が何を試みても、フォローアップセーブのためにサービスを打ちようとすると、EFコンテキストは既に更新されています。

Answer 1

これはトランザクションとは関係ありません。トランザクションはトランザクションリソース上で動作しますが、最初のリクエストでSaveChangesを呼び出すことなく、EFコンテキストはトランザクションの一部ではないため、トランザクションリソースはアクティブではありませんでした - データベースはデータベースであり、データベースはSaveChangesこの作業を行うには、分散トランザクションは必要ありません。セッションフルサービスが必要で、EFコンテキストをサービスインスタンスに格納します。クライアントは同じクライアントインスタンスを使用して、同じサービスインスタンスによって通信が処理されるすべての要求に対してサービスと通信します。以前の呼び出しからの変更を記憶する同じEFコンテキストインスタンスです。

IMHOこれは非常に悪いアーキテクチャです。単にそれを使用しないでください。変更を行い、保存するWCFサービスの特殊なメソッドを公開します。他のトランザクションリソースとのトランザクションでこれらのメソッドを実行する必要がある場合は、実際の分散トランザクションを使用します。

Answer 2

これは理由があります。あなたが別の状況で更新を行っているからです。コンテキストはオブジェクトが更新されていることを知らないので、オブジェクトが変更されたことを知らせてからsavechnages（）を呼び出します。役立つかどうかを確認する