寻求一种通用的基于上下文的存储

Question

首先，我希望基于上下文的存储在整个框架中保持一致！

尽管如此，我正在寻找一种优雅的解决方案，使这些属性在 ASP.NET、WCF 和任何其他多线程 .NET 代码中安全。 这些属性位于一些低级跟踪助手中（如果您想知道为什么它们是内部的，则可以通过方法公开这些属性）。

我不想依赖不需要的程序集（如 System.Web 等）。 我不想要求任何人使用此代码来配置任何内容。 我只是想让它发挥作用；）不过，这可能有点太高了……

有人有什么秘诀吗？ （我已经看过Spring的实现）

    internal static string CurrentInstance
    {
        get
        {
            return CallContext.LogicalGetData(currentInstanceSlotName) as string;
        }
        set
        {
            CallContext.LogicalSetData(currentInstanceSlotName, value);
        }
    }

    internal static Stack<ActivityState> AmbientActivityId
    {
        get
        {
            Stack<ActivityState> stack = CallContext.LogicalGetData(ambientActivityStateSlotName) as Stack<ActivityState>;
            if (stack == null)
            {
                stack = new Stack<ActivityState>();
                CallContext.LogicalSetData(ambientActivityStateSlotName, stack);
            }

            return stack;
        }
    }

Update

By safe 我不是指同步。 有关该问题的背景信息此处

Answer 1

以下是 NHibernate“上下文”实现（至少部分）的链接：

https://nhibernate.svn.sourceforge.net/svnroot/nhibernate/trunk/nhibernate/src/NHibernate/Context/

我不清楚这到底在哪里或如何发挥作用NHibernate 的上下文。 也就是说，如果我想在“上下文”中存储一些值，我会从 NHibernate 获取“上下文”并添加我的值吗？ 我不使用 NHibernate，所以我不太知道。

我想您可以自己查看并确定这种实现是否对您有用。 显然，这个想法是根据应用程序的类型（ASP.NET、WCF 等）注入所需的实现。 这可能意味着一些配置（如果要使用 MEF 加载“ICurrentSessionContext 接口”，则可能是最小的配置）。

无论如何，当我前段时间在 CallContext.SetData/GetData/LogicalSetData/LogicalGetData、Thread.SetData/GetData 上搜索信息时发现这个想法很有趣、[ThreadStatic] 等。

另外，根据您使用 CallContext.LogicalSetData 而不是 CallContext.SetData，我假设您想要利用与逻辑线程关联的信息将传播到子线程这一事实，而不是仅仅想要一个“线程安全”的地方来存储信息。 因此，如果您要在应用程序启动时设置（pr Push）AmbientActivity，然后不再推送任何活动，则任何后续线程也将成为同一活动的一部分，因为通过 LogicalSetData 存储的数据由子线程继承。

如果自从您第一次问这个问题以来您在此期间学到了任何东西，我将非常有兴趣听到它。 即使您没有，我也会有兴趣了解您在上下文中所做的事情。

目前，我正在努力维护一些用于日志记录/跟踪的上下文信息（类似于 Trace.CorrelationManager.ActivityId 和 Trace.CorrelationManager.LogicalOpertionStack 和 log4net/NLog 上下文支持）。 我想保存一些上下文（当前应用程序、当前应用程序实例、当前活动（可能是嵌套的））以在应用程序或 WCF 服务中使用，并且我想跨 WCF 服务边界“自动”传播它。 这是为了允许记录在中央存储库中的日志记录语句与客户端/活动/等相关联。 我们将能够通过特定应用程序的特定实例查询和关联所有日志记录语句。 日志记录语句可能是在客户端或一个或多个 WCF 服务中生成的。

ActivityId 的 WCF 传播对我们来说不一定足够，因为我们想要传播（或者我们认为我们这样做）的不仅仅是 ActivityId。 另外，我们希望将此信息从 Silverlight 客户端传播到 WCF 服务，而 Trace.CorrelationManager 在 Silverlight 中不可用（至少在 4.0 中不可用，也许将来会提供类似的功能）。

目前，我正在使用 IClientMessageInspector 和 IDispatchMessageInspector 对“上下文”信息的传播进行原型设计。 看起来它可能对我们来说没问题。

关于对 System.Web 的依赖，NHibernate 实现确实有一个“ReflectiveHttpContext”，它使用反射来访问 HttpContext，因此不会存在对 System.Web 的项目依赖。 显然，如果配置使用 HttpContext，则部署应用程序的地方必须可用 System.Web。

Answer 2

如果只是为了提供对属性的线程安全访问，我不知道使用 CallContext 是正确的选择。 如果是这种情况，那么您只需要 lock 语句。

但是，您必须确保正确应用它。。

使用 CallContext，您将获得线程安全的访问，因为当调用进入不同的线程（或不同的存储）时，您将拥有单独的 CallContext 实例。 但是，这与对资源的线程安全访问有很大不同。

如果您想在多个线程之间共享相同的值，那么 lock 语句就是最佳选择。 否则，如果您需要基于每个线程/调用的特定值，请使用 CallContext，或使用 Thread 类上的静态 GetData/SetData 方法，或 ThreadStatic 属性（或任意数量的基于线程的存储机制）。