【问题标题】:EF dynamic proxies in Session Azure Cache会话 Azure 缓存中的 EF 动态代理
【发布时间】:2012-02-17 07:52:52
【问题描述】:

我们在 Windows Azure 环境中使用 Entity Framework,直到现在我们使用 InProc 会话状态,但你们中的一些人可能知道,由于它是分布式的,我们应该使用另一种方法,这就是我们激活 Azure 的原因AppFabric 缓存。

激活此会话状态提供程序时,我们开始出现以下异常:

ObjectDisposedException: The ObjectContext instance has been disposed and can no longer be used for operations that require a connection.]
       System.Data.Objects.ObjectContext.EnsureConnection() +11658009
       System.Data.Objects.ObjectQuery`1.GetResults(Nullable`1 forMergeOption) +66
       System.Data.Objects.DataClasses.EntityCollection`1.Load(List`1 collection, MergeOption mergeOption) +271
       System.Data.Objects.DataClasses.RelatedEnd.DeferredLoad() +499
       System.Data.Objects.Internal.LazyLoadBehavior.LoadProperty(TItem propertyValue, String relationshipName, String targetRoleName, Boolean mustBeNull, Object wrapperObject) +136
       System.Data.Objects.Internal.<>c__DisplayClass7`2.<GetInterceptorDelegate>b__1(TProxy proxy, TItem item) +153
       System.Data.Entity.DynamicProxies.SysUser_1A4439A55EAE70AD5C976139AA3A390B54A2C96E5FA605B3F364F0ADF52D0707.get_Assignments() +151
       WriteSysUser_1A4439A55EAE70AD5C976139AA3A390B54A2C96E5FA605B3F364F0ADF52D0707ToXml(XmlWriterDelegator , Object , XmlObjectSerializerWriteContext , ClassDataContract ) +544
...

当 AppFabric 尝试序列化 EF 对象以进行缓存时,似乎会引发此异常。

我们使用的 EF 带有 LazyLoading 和 ProxyCreation 标志都处于活动状态,在这种情况下似乎不支持,但它在 InProc Session 状态管理中。

我们正在寻找一些关于如何将 Azure AppFabric 会话状态提供程序与 EF 一起使用的建议,同时保持延迟加载。

谢谢, 瑞

【问题讨论】:

    标签: entity-framework session azure


    【解决方案1】:

    您不能对任何类型的会话使用延迟加载和动态代理。如果它与 InProc 一起使用,则可能是由于对 EF 上下文生存期的无效处理,或者您很幸运并且仅在其上下文范围内访问了缓存的对象。

    延迟加载需要活的上下文,而上下文应该只为执行单个工作单元而存在。因此,您不能要求支持缓存实体的延迟加载。缓存的实体根本不应该被代理(代理对它们没有意义)并且必须分离。

    【讨论】:

    • 感谢您的回答,关于它在使用 InProc 会话时可以正常工作,我唯一的猜测是序列化是以不同的方式完成的,因为它似乎是引发错误的地方,而我们唯一要做的就是'在项目中改变的是 Session 配置,从 InProc 到 Azure 缓存,所有其他逻辑都是一样的。由于我们仍然想要延迟加载,是否可以在会话中存储实体?如果是这样,这样做的方法是首先分离它们?我们该怎么做?
    • InProc 会话不使用任何序列化。它只是保存对现有对象的引用。您可以简单地通过在上下文中调用 Detach 来分离实体,但是一旦您这样做,它将不再允许延迟加载,这就是关键 - 存储在会话中的实体以后不能使用延迟加载。
    • 我知道缓存这些实体的延迟加载后不再可用。在将实体发送到会话之前简单地调用 detach 似乎不起作用。为了更清楚,我现在的目标是在其余逻辑中保持延迟加载的同时,能够存储一些 EF 实体以与基本属性(真正的 POCO)进行会话。你知道在不创建新类的情况下实现这一点的方法吗?
    • 您可以在运行时有选择地关闭延迟加载或代理创建(检查ContextOptions 属性)。您知道某些实体将被传递到缓存,因此使用配置为不使用代理创建进行加载的上下文,您的应用程序的其余部分仍然可以使用配置为使用代理和延迟加载的上下文。顺便提一句。似乎没有工作不是问题的描述。
    • 只是分离不起作用,因为我还有一些(不同的反序列化错误,例如“无法设置 YY 类型的属性 XX,因为集合已设置为 EntityCollection。”)。在运行时关闭延迟加载,作为本地事物,它仍然会阻止它在当前上下文范围内的使用。我想我必须找到另一种方法来在会话中存储这些信息。
    猜你喜欢
    • 2015-03-25
    • 2012-04-25
    • 1970-01-01
    • 1970-01-01
    • 2013-06-12
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多