【问题标题】:Integrate Pooled Lifestyle with PerWebRequest Lifestyle in Windsor在 Windsor 中将 Pooled Lifestyle 与 PerWebRequest Lifestyle 集成
【发布时间】:2012-08-08 13:14:07
【问题描述】:

我有使用实体框架作为 ORM 的 ASP.NET MVC 应用程序。 现在我正在为 EF ObjectContext 使用 PerWebRequest 生活方式。

在高负载下分析应用程序性能时,我发现 ObjectContext 创建的瓶颈。

我想将ObjectContext的生活方式改为Pooled,但是有一个问题。

在我的应用程序的遗留部分有 Service Locator 反模式。因此 ObjectContext 可以在每个 Web 请求中多次解析,并且在使用后不会显式释放。

使用 PerWebRequest 这不是问题,因为 ObjectContext 实例实例化一次并在 EndRequest 事件时保证释放。

对于默认的 Pooled 生活方式,每个 Resolve 方法调用都会返回不同的 ObjectContext 实例。但我想在 Web 请求范围内重新使用单个实例。 我还希望实例在请求结束时自动释放(返回池)(使用 PerWebRequestLifestyleModule)。

在我看来,我应该为 Windsor 实现自定义 LifestyleManager 或自定义 IPool。 但由于缺乏温莎经验,我不知道如何结合 PooledPerWebRequest 生活方式。

你能给我一些想法吗? 谢谢。

UPD:关于 ObjectContext 的状态和重用原因

有性能原因。 ObjectContext 的创建非常昂贵。我正在寻找避免它的方法。 我有两种方法来处理 ObjectContext 的有状态特性并重用它:

  • 对查询使用无状态上下文(关闭 ChangeTracking)。对于命令,请使用另一个实例。
  • 返回池时重置上下文的状态。

【问题讨论】:

    标签: .net castle-windsor pool perwebrequest


    【解决方案1】:

    不要在请求之间重复使用 ObjectContext。您将在请求之间(以及可能在用户之间)泄漏共享状态。 ObjectContext 类不是为重复使用而设计的。

    在您的问题中,我没有找到不使用PerWebRequest 的理由,所以就使用它吧。

    【讨论】:

    • 感谢您的回答。查看我的更新以了解原因。
    • 请注意,我建议按请求重用上下文。这绝对是正确的做法。为每个请求创建一个上下文几乎是不可估量的。如果您不这么认为,我很想看看您的测量结果。无状态上下文可能会起作用,我对 EF 的了解还不够多。不确定是否可以重置上下文的状态。 请注意,您在这里引入了非确定性元素。 通常,请求是 100% 孤立的,但现在不是。这就像线程错误:非确定性的,不可调试的。如果这是我作为领导的决定,我会禁止这样做。
    【解决方案2】:

    在您的情况下,您可以更改绑定到当前线程的生活方式,确保网络应用中的每个工作线程都获得一个实例

    【讨论】:

    • 不,不应重用 ObjectContext 类。此外,单个 ASP.NET 请求可以在多个线程上执行(非并发,但仍然在多个线程上)。
    • 对!我不是那种实体框架的人 - 从我推断出 ObjectContext 实际上可以重用的问题是因为他自己建议使用池化生命周期
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2011-06-03
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-03-02
    相关资源
    最近更新 更多