EF上下文容器,保存线程唯一性

在工作中有个疑问,就是EF上下文容器到底创建了多少个?

在asp.net中,EF上下文容器。如果只要有一个,则每次一个用户访问,添加一些实体,然后又不会自动销毁,就会造成内存爆炸。如果每次创建一个,则就出现一个实例调用混乱。在sp.net中,保证一个线程(一次http请求及一个管道事件),一个EF上下文容器就刚刚好,解决上面问题。

一个线程一个上下文容器,

解决方案1:线程缓存

保证一个请求线程中只有一份EF容器
        protected BaseDbContext db
        {
            get
            {
                //向线程缓存中查询,如果返回的是null,则创建,同时存入到这个线程缓存中
                //注意的是线程缓存CallContext,而不是我们熟悉的HttpRuntime.cache
                object efDbContext = CallContext.GetData("BaseDbContext");
                if (efDbContext == null)
                {
                    efDbContext = new BaseDbContext();
                    //存入到这个线程缓存中
                    CallContext.SetData("BaseDbContext", efDbContext);
                }
                return efDbContext as BaseDbContext;
            }
        }

方案2:将上下文容器保存到httpContext.Current.Items["db"]中(httpContext也是每次请求创建一个,管道事件结束就销毁)

public static class EFFactory
        {
            public static object GetCurrentEFContext()
            {
                if (HttpContext.Current.Items["EFContxt"]==null)
                {
                    HttpContext.Current.Items["EFContxt"]= new BaseDbContext();
                }
                return HttpContext.Current.Items["EFContxt"];
            }
        }

时间: 2024-10-12 08:50:56

EF上下文容器,保存线程唯一性的相关文章

EF上下文对象线程内唯一性与优化

在一次请求中,即一个线程内,若是用到EF数据上下文对象,就创建一个,这也加是很多人的代码中习惯在使用上下文对象时,习惯将对象建立在using中,也是为了尽早释放上下文对象, 但是如果有一个业务逻辑调用了多个dal层的方法,交互数据库多次,这样效率会低一些,而且在使用EF的情况下,我们通常把SaveChange这个方法提到业务逻辑层(下文中会提到),不保证同一个业务逻辑使用的是同一个上下文对象,事务,工作单元模式将无法实现.而且可能造成数据混乱,每次创建的对象执行相应的数据库操作,与此同时,同一次

EF上下文对象创建之线程内唯一

在一次请求中,即一个线程内,若是用到EF数据上下文对象,就创建一个,那么会造成数据混乱,每次创建的对象执行相应的数据库操作,此同时,其他的EF对象内获得的数据可能已经是“过期”的了.即这个数据已经变动过.这就是数据混乱,为了解决这个问题,关键就是对象的创建问题. 这里首先想到单例模式,不过在这里,不适合用,原因是使用单例模式,会使EF对象得不到及时的资源释放. 第二种方式即保证在线程内对象唯一,如何保证呢,通过微软ASP机制的HttpContext对象,这个对象在线程中是唯一的,所以我们在Htt

【无私分享:ASP.NET CORE 项目实战(第二章)】添加EF上下文对象,添加接口、实现类以及无处不在的依赖注入(DI)

目录索引 [无私分享:ASP.NET CORE 项目实战]目录索引 简介 上一章,我们介绍了安装和新建控制器.视图,这一章我们来创建个数据模型,并且添加接口和实现类. 添加EF上下文对象 按照我们以前的习惯,我们还是新建几个文件夹 Commons:存放帮助类 Domians:数据模型 Services:接口和实现类 我们在Domains文件夹下添加一个类库 Domain 我们新建一个类 ApplicationDbContext 继承 DbContext 1 using Microsoft.Ent

过滤器、监听器、上下文、servlet线程安全问题

就像名字写那样,过滤器可以过滤请求,比如对一些评论进行过滤.又不改原有代码的基础上可以加上一个过滤器,或者是登陆验证.集中在一个过滤器中处理.写一个类实现接口 Filter 之后一定要在配置文件中配置!!!监听器可以监听,上下文的概念. 过滤器: 什么是过滤器: servlet规范当中定义的一种特殊的组件,用来拦截servlet容器的调用过程. 会先调过过滤器的方法,过滤器决定是否向后继续调用就是调用servlet容器 容器收到请求之后 通常情况下会调用servlet的service方法来处理请

ASP.NET MVC+EF框架+EasyUI实现权限管理系列(6)- EF上下文实例管理

原文:ASP.NET MVC+EF框架+EasyUI实现权限管理系列(6)- EF上下文实例管理 ASP.NET MVC+EF框架+EasyUI实现权限管系列 (开篇)   (1):框架搭建    (2):数据库访问层的设计Demo    (3):面向接口编程   (4 ):业务逻辑层的封装  (5):前台Jquery easyUI实现 前言:通过前面的五篇博客我们已经对权限系统的后台架构进行了详细的说明,那么我再前面的博客中也说到了我们的后台架构还会再改的,我准备这段时间我们继续完善我们的后台

ARMv7处理器各个模式之间是如何切换的?模式切换时上下文的保存哪些是硬件在做?哪些是操作系统在做?

1.ARM处理器各个模式之间是如何切换的? 答:除用户模式外的其他6种模式称为特权模式,这些模式中,程序可以访问所有系统资源,也可以任意进行处理器模式的切换.处理器模式可以通过软件控制进行切换(直接设置CPSR寄存器的后五位就可以在6种特权模式之间互相切换),也可以通过外部中断或异常处理过程进行切换(例如,在USR模式下,发生中断后切换到IRQ模式). 2.ARM各个模式之间切换时,上下文的保存哪些是硬件在做?哪些是操作系统在做? 答:CPU做的: (1)把返回地址保存到相应模式的lr寄存器中,

ARMv7处理器各个模式之间是怎样切换的?模式切换时上下文的保存哪些是硬件在做?哪些是操作系统在做?

1.ARM处理器各个模式之间是怎样切换的? 答:除用户模式外的其它6种模式称为特权模式,这些模式中,程序能够訪问全部系统资源,也能够随意进行处理器模式的切换.处理器模式能够通过软件控制进行切换(直接设置CPSR寄存器的后五位就能够在6种特权模式之间互相切换),也能够通过外部中断或异常处理过程进行切换(比如,在USR模式下,发生中断后切换到IRQ模式). 2.ARM各个模式之间切换时,上下文的保存哪些是硬件在做?哪些是操作系统在做? 答:CPU做的: (1)把返回地址保存到对应模式的lr寄存器中,

抽象工厂 控制EF上下文 单例

public class ObjectContextFactory { public static System.Data.Objects.ObjectContext GetCurrentObjectContext() { //从CallContext数据槽中获取EF上下文 ObjectContext objectContext = CallContext.GetData(typeof(ObjectContextFactory).FullName) as ObjectContext; if (o

EF上下文管理

1.一次请求过来与数据库交互一次.每次操作表都using() 性能差(可以随时释放) 2.N 次操作共用一个DbContext 性能可想而知 3.Web:一个请求共用一个上下文实例 4.WinForm:用using() 实例: public static MyDbContext GetCurrentDbContext() { MyDbContext dbcontext = HttpContext.Current.Items["MyDbContext"] as MyDbContext;