在多线程服务器中使用实体框架的最佳实践是什么？
我正在使用实体框架ObjectContext来管理我的所有数据库操作，现在我知道这个上下文不是线程安全的，所以现在当我需要使用它来执行一些db操作时，为了安全起见，我用lock语句将它包围起来。我应该这样做吗
多线程环境中实体框架的一些快速建议：
- 不要对
锁使用唯一上下文（无单例模式） - 提供无状态服务（您需要为每个请求实例化和处置一个上下文）
- 尽可能缩短上下文生存期
- 实现一个并发控制系统。乐观并发可以通过实体框架（how-to）轻松实现。这将确保在使用非最新实体时不会覆盖数据库中的更改
我有点困惑，我认为使用一个上下文是好的，因为
我相信它会有一些吸引人的地方，所以当我处理同样的问题时
在连续的请求中，使用相同的
然后每次创建一个新的上下文。那么，为什么这样做很好呢
如果它速度较慢且仍然不是线程安全的，请这样使用它
你可以只使用一个上下文，但除非你真的知道自己在做什么，否则这是非常不鼓励的
我看到这种方法经常出现两个主要问题：
-
您将使用大量内存，因为您的上下文永远不会被释放，所有被操纵的实体都将被缓存在内存中（查询结果中出现的每个实体都会被缓存）
-
如果修改来自另一个程序/上下文的数据，您将面临许多并发问题。例如，如果直接在数据库中修改某些内容，并且关联的实体已缓存在唯一的上下文对象中，则上下文永远不会知道直接在数据库中进行的修改。您将使用非最新的缓存实体，相信我，这将导致很难找到和修复问题
也不用担心使用多个上下文的性能：在90%的用例中，每个请求创建/处理一个新上下文的开销几乎是微不足道的。请记住，创建新上下文并不一定会创建到数据库的新连接（因为数据库通常使用连接池）