是否可以在 asp.net 中使用静态 LINQ to SQL DataContext 维护事务?
- 作者: 亖呉?盀
- 来源: 51数据库
- 2022-12-13
问题描述
我有一个使用 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 ****!
除此之外,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.
- C#通过fleck实现wss协议的WebSocket多人Web实时聊天(附源码)
- 团队城市未满足要求:MSBuildTools12.0_x86_Path 存在
- 使用 MSBuild.exe 在发布模式下构建 C# 解决方案
- 当我发布 Web 应用程序时,AfterPublish 脚本不运行
- 构建时 T4 转换的产品仅在下一个构建中使用
- ASP.NET Core Application (.NET Framework) for Windows x64 only error in project.assets.json
- 新的 .csproj 格式 - 如何将整个目录指定为“链接文件"到子目录?
- 如何将条件编译符号(DefineConstants)传递给 msbuild
- MSBuild 支持 Visual Studio 2017 RTM 中的 T4 模板
- NuGet 包还原找不到包,没有源
