.net ORM に関する質問が何千回も寄せられていることは知っていますが、どの ORM がマルチスレッド環境で簡単に操作できるか知りたいです。商用または無料の両方を歓迎します。
現在、Devexpress の XPO を使用していますが、マルチスレッド アプリでの使用に違和感があります。あるスレッドのオブジェクトを別のスレッドで共有することはできません。別のスレッドで使用するには、キーを使用して DB からオブジェクトを見つける必要があります。これは本当に面倒です。オブジェクトの状態をロックしても、DB オブジェクトの状態を DB に永続化することはできません。たとえば、オブジェクトを作成したスレッド以外の別のスレッドから Save() メソッドを呼び出すことはできません。
ところで、私は XPO を使い始めたばかりで、間違った使い方をしているのかもしれません。
すべてのO/RMは、マルチスレッドアプリケーションで完全に機能します。ASP.NETアプリケーション（定義ごとにマルチスレッド化されている）でLINQtoSQLとEntityFrameworkを使用しました。
マルチスレッド環境でO/RMを使用する際に問題が発生した場合は、おそらく間違って使用しています。たとえば、ほとんどのO / RMツールには、作業単位パターンを実装するタイプがあります（LINQ to SQL DataContext、Entity Framework ObjectContext、XPOなどSession）。作業単位は、単一のスレッドによって作成および制御されることを目的としています。このようなオブジェクトをこのように使用する場合、マルチスレッド環境でO/RMツールを使用する際に問題が発生したことはありません。
nHibernateは多くのアプリケーションで使用されており、そのうちのいくつかはマルチスレッドです。
concurrencyに関するドキュメント、特にセクションを参照してください-それはスレッドセーフではない10.2ことを明確に示しています（したがって、これを自分で管理する必要があります）。ISession
あなたに関する限り、ORM を「作業しやすい」ものにする要素を明確にしていただけますか?
Entity Framework の ObjectContext はどちらもスレッド セーフではないため、共有リソースとして使用する場合は、ロックを使用して独自に実装する必要があります。
すべてのスレッドに対して新しいオブジェクト コンテキストを作成することもできますが、多くのスレッドが生成または消滅している場合、これは簡単にパフォーマンスの問題になる可能性があります。
また、スレッドごとに ObjectContext があると、データが古くなる可能性があります。以下に述べるように：
最後になりましたが、もちろん、マルチユーザーの同時実行の問題です。ObjectContext は、エンティティが破棄されるまで永久にキャッシュします。別のユーザーが自分の ObjectContext で同じエンティティを変更した場合、最初の ObjectContext の所有者はその変更を知ることはありません。これらの古いデータの問題は、クエリがデータベースに移動して新しいデータが返されるのを実際に見ることができるため、デバッグが非常に困難になる可能性がありますが、ObjectContext は既にキャッシュにある古い古いデータで上書きします。私の意見では、これはおそらく、長寿命の ObjectContext インスタンスを避ける最も重要な理由です。データベースから最新のデータを取得するようにコーディングしたと思われる場合でも、ObjectContext は自分よりも賢いと判断し、代わりに古いエンティティを返します。