问题描述
我有一个使用 LINQ to SQL 与 SQL 服务器连接的 ASP.NET 应用程序.当我有一个静态类时,它当然可以在应用程序级别上工作.我在这个静态类中创建了 DataContext
的静态对象.除了这个,我没有在应用程序中创建任何数据上下文对象.当我为每个数据库操作使用这个静态数据上下文对象时.
I have ASP.NET application which is connected with SQL server using LINQ to SQL. Where as i have a static class , certainly it would work on application level. Where as I have created static object of DataContext
in this static class.
I have not created any data context object in application except this. Where as i am using this static data context object for each data base manipulation.
那么这是否会将事务保持为每个登录用户的线程安全?
So will this maintain the transaction as thread-safe for each logged in user?
推荐答案
注意:以下建议适用于所有实现工作单元模式的 O/RM 工具,例如实体框架的 ObjectContext
、DbContext
、NHibernate 的 Session
和 LINQ to SQL 的 DataContext
.
Note: the following advice holds for all O/RM tools that implement the unit of work pattern such as Entity Framework's ObjectContext
, DbContext
, NHibernate's Session
, and LINQ to SQL's DataContext
.
LINQ to SQL DataContext 不是线程安全的.您应该为每个 Web 请求创建(至少)1 个上下文.在多个线程上重用同一个实例意味着一个线程可以调用 SubmitChanges
而另一个线程仍在插入新对象.如果你很幸运,DataContext
会抛出一个异常,因为它不能持久化更改.如果您不走运,DataContext
会成功并破坏单个请求的原子性,这可能会导致数据库中的数据不一致.换句话说:你将拥有一个满是狗屎的数据库!
The LINQ to SQL DataContext is NOT thread-safe. You should create (at least) 1 context per web request. Reusing the same instance over multiple threads means that one thread can call SubmitChanges
while another thread is still inserting new objects. If you're lucky the DataContext
will throw an exception, because it cannot persist the changes. If you're unlucky, the DataContext
succeeds and you break the atomicy of a single request, which can cause you to have inconsistent data in your database. In other words: You'll have a database full of shit!
除此之外,DataContext
将所有对象保存在其缓存中,这意味着您的应用程序的内存消耗将不断增长,这可能导致 OutOfMemoryException
(OOM).即使您不会收到 OOM,缓存中的对象也会过时,特别是如果其他应用程序或进程正在更新您的数据库,当实体已经在内存中时,您将永远不会看到这些更改.最后要注意的是,您无法回滚在 DataContext
中所做的更改,因此当您(一度)使 DataContext
无效时(由于错误)没有办法恢复它(除了创建一个全新的 DataContext
).在这种情况下,您的 AppDomain 注定要失败.
Besides that, the DataContext
keeps all objects in its cache, which mean that the memory consumption of your application will keep growing, which can lead to an OutOfMemoryException
(OOM). And even if you won’t get an OOM, the objects in the cache get stale and especially if other applications or processes are updating your database, you will never see those changes when an entity is already in memory. And last thing to note is that there is no way for you to rollback changes made in the DataContext
so when you (at one point) invalidated the DataContext
(because of errors) there is no way to restore this (except from creating a totally new DataContext
). In that case your AppDomain is doomed.
这篇关于是否可以在 asp.net 中使用静态 LINQ to SQL DataContext 维护事务?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持跟版网!