c# 在多线程服务器中使用实体框架 [英] c# working with Entity Framework in a multi threaded server
问题描述
在多线程服务器中使用实体框架的最佳实践是什么?我正在使用实体框架 ObjectContext 来管理我所有的数据库操作，现在我知道这个上下文不是线程安全的，所以现在当我需要使用它来执行一些数据库操作时，我用lock 语句是安全的.这是我应该做的吗??
What is the best practice for working with entity framework in a multi threaded server?
I'm using entity framework ObjectContext to manage all my database actions, now I know this context isn't thread safe, so for now when I need to use it to perform some db actions I surround it with lock statement to be safe. Is this how I should do it??
推荐答案
针对多线程环境中实体框架的一些快速建议:
Some quick advices for Entity Framework in a multi-threaded environment:
- 不要在
locks中使用唯一的上下文(无单例模式) - 提供无状态服务(您需要为每个请求实例化和处理一个上下文)
- 尽可能缩短上下文生命周期
- 实施并发控制系统.使用实体框架可以轻松实现乐观并发(操作方法).这将确保您在使用不是最新的实体时不会覆盖数据库中的更改
- Don't use a unique context with
locks(no singleton pattern) - Provide stateless services (you need to instantiate and dispose one context per request)
- Shorten the context lifetime as much as possible
- Do implement a concurrency-control system. Optimistic concurrency can be easily implemented with Entity Framework (how-to). This will ensure you don't overwrite changes in the DB when you use an entity that is not up-to-date
我有点困惑，我认为使用一种上下文很好，因为我相信它确实会抓住一些东西，所以当我处理同样的事情时实体在连续请求中使用相同的要快得多然后每次都创建一个新的上下文.那么为什么这样做有好处如果速度较慢并且仍然不是线程安全的，请像这样使用它?
I'm a bit confused, I thought that using one context is good because it does some catching I believe, so when I'm dealing with the same entity in consecutive requests it be much faster to use the same context then creating a new context every time. So why does it good to use it like this if It slower and still not thread safe?
您可以只使用一种上下文，但强烈建议您除非您真的知道自己在做什么.
You could use only one context, but it's strongly discouraged unless you really know what you are doing.
我发现这种方法经常出现两个主要问题:
I see two main problems that often happen with such an approach:
您将使用大量内存，因为您的上下文永远不会被释放，并且所有被操纵的实体都将缓存在内存中(出现在查询结果中的每个实体都被缓存).
you'll use a lot of memory as your context will never be disposed and all manipulated entities will be cached in memory (each entity that appears in the result of a query is cached).
如果您从另一个程序/上下文修改数据，您将面临许多并发问题.例如，如果您直接在数据库中修改某些内容并且关联实体已经缓存在您唯一的上下文对象中，那么您的上下文永远不会知道直接在数据库中进行的修改.您将使用不是最新的缓存实体，相信我，它会导致难以查找和修复的问题.
you'll face lots of concurrency issues if you modify you data from another program/context. For example, if you modify something directly in your database and the associated entity was already cached in your unique context object, then your context won't ever know about the modification that was made directly in the database. You'll work with a cached entity that is not up-to-date, and trust me, it'll lead to hard-to-find-and-fix issues.
也不要担心使用多个上下文的性能:在 90% 的用例中，每个请求创建/处理新上下文的开销几乎微不足道.请记住，创建新上下文并不一定会创建到数据库的新连接(因为数据库通常使用连接池).
Also don't worry about performances of using multiple contexts: the overhead of creating/disposing a new context per request is almost insignificant in 90% of use cases. Remember that creating a new context does not necessarily create a new connection to the database (as the database generally uses a connection pool).
这篇关于c# 在多线程服务器中使用实体框架的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
