性能优化总结(五):CSLA服务端如何使用多线程的解决方案

    前篇说到了使用异步线程来实现数据的预加载,以提高系统性能。

    这样的操作一般是在客户端执行,用以减少用户的等待时间。客户端发送多次异步请求,到达服务端后,如果服务端不支持多线程处理操作,线性处理各个请求,必然导致客户端的异步请求变得没有意义。

    大家肯定会说,谁会把服务端设计成单线程的啊,那不是明显的错误吗?是的!但是我们的系统使用了CSLA来作为实现分布式的框架,而它的服务端程序却只能支持单线程……这个问题我们一直想解决,但是查过CSLA官方论坛,作者说由于GlobalContext和ClientContext的一些原因,暂时不支持多线程。火大,这还怎么用啊!无奈目前系统已经极大地依赖了这个框架,一时半会儿要想换一个新的,也不太现实。所以只好自己动手修改CSLA里面的代码了:

修改WCF通信类

    要修改为多线程的服务端,首先得从服务端的请求处理处入手。.NET3.5的CSLA框架使用WCF实现数据传输。它在服务器端使用这个类来接收:

namespace Csla.Server.Hosts
{
    [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
    [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
    public class WcfPortal : IWcfPortal { }
}

可以看到,这个类没有标注ConcurrencyMode = ConcurrencyMode.Multiple和UseSynchronizationContext = false,所以已经被设计为单线程操作。在这里,我们使用装饰模式来构造一个新的类:

/// <summary>
/// 标记了ConcurrencyMode = ConcurrencyMode.Multiple
/// 来表示多线程进行
/// </summary>
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall,
ConcurrencyMode = ConcurrencyMode.Multiple,
UseSynchronizationContext = false)]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class MultiThreadsWCFPortal : IWcfPortal
{
    private WcfPortal _innerPortal = new WcfPortal();
    #region IWcfPortal Members
    public WcfResponse Create(CreateRequest request)
    {
        return this._innerPortal.Create(request);
    }
    //...
    #endregion
}

同时,我们需要把配置文件和类的实例化两处代码都替换:

app.config:

<services>
    <!--Csla.Server.Hosts.WcfPortal-->
    <service name="OpenExpressApp.Server.WPFHost.MultiThreadsWCFPortal" behaviorConfiguration="returnFaults">
.....
</service>
</services>

factory method:

private static Type GetServerHostType()
{
    return typeof(OpenExpressApp.Server.WPFHost.MultiThreadsWCFPortal);
    //return typeof(Csla.Server.Hosts.WcfPortal);
}

这样,在服务端接收到请求时,会自动开启多个线程来响应请求。同时,装饰模式的使用使得我们不需要对源代码进行任何更改。

修改ApplicationContext._principal字段

    按照上面的操作修改之后,已经在WCF级别上实现了多线程。但是当再次运行应用程序时,会抛出NullRefrenceException异常。代码出现在这里:

var currentIdentity = Csla.ApplicationContext.User.Identity as OEAIdentity;
currentIdentity.GetDataPermissionExpr(businessObjectId);

调试发现,Csla.ApplicationContext.User是一个UnauthenticatedIdentity的实例。可是我们已经登录了,这个属性为什么还是“未授权”呢?查看源代码,发现每次在处理请求的开始阶段,CSLA会设置这个属性为客户端传入的用户标识。那么我们来看这个属性在CSLA中的源代码:

private static IPrincipal _principal;
public static IPrincipal User
{
    get
    {
        IPrincipal current;
        if (HttpContext.Current != null)
            current = HttpContext.Current.User;
        else if (System.Windows.Application.Current != null)
        {
            if (_principal == null)
            {
                if (ApplicationContext.AuthenticationType != "Windows")
                    _principal = new Csla.Security.UnauthenticatedPrincipal();
                else
                    _principal = new WindowsPrincipal(WindowsIdentity.GetCurrent());
            }
            current = _principal;
        }
        else
            current = Thread.CurrentPrincipal;
        return current;
    }
    set
    {
        if (HttpContext.Current != null)
            HttpContext.Current.User = value;
        else if (System.Windows.Application.Current != null)
            _principal = value;
        Thread.CurrentPrincipal = value;
    }
}

代码中显示,如果服务端使用的是WPF应用程序时,就使用一个静态字段保存当前的用户。这就是说服务端的所有线程都只能获取到最后一个请求的用户,当然就不能提供多线程的服务!这里,其实是作者的一个小BUG:他认为使用WPF的程序应该就是客户端,所以直接存储在静态变量中。但是我们的服务端也是WPF来实现的,所以就导致了无法为每个线程使用独立的数据。

这个类同时被客户端和服务端所使用,所以改动不能影响客户端的正常使用。为了最少地改动原有代码,我把字段的代码修改为:

[ThreadStatic]
private static IPrincipal __principalThreadSafe;
private static IPrincipal __principal;
private static IPrincipal _principal
{
    get
    {
        return _executionLocation == ExecutionLocations.Client ? __principal : __principalThreadSafe;
    }
    set
    {
        if (_executionLocation == ExecutionLocations.Client)
        {
            __principal = value;
        }
        else
        {
            __principalThreadSafe = value;
        }
    }
}

这里把原来的字段变为了一个属性!实现它时,如果是在客户端,还是使用一个一般的静态字段。如果是在服务端时,就换成了一个标记了[ThreadStatic]的字段,该标记表示:这个字段会为每一个线程分配独立的值。这样,服务端在请求被处理的开始阶段对_principal赋值时,就存储在了当前线程中,而不会影响其它线程。

手动开启的线程

    上面已经解决了两个问题:1、默认没有打开多线程;2、多个线程对ApplicationContext.User类赋值时,使用静态字段导致值的冲突。

    这样就高枕无忧了吗?答案是不!:)

    这样只是保证了WCF用于处理请求的线程中,ApplicationContext.User属性的值是正确的。但是我们在处理一个单独的请求时,又很有可能手工打开更多的线程来为它服务。这些线程的ApplicationContext.User字段并没有被CSLA框架赋值,如果这时使用到它时,又会出现NullRefrenceException……

    由于我们进行异步处理时的代码都是经过一层细微的封装的,所以这时候好处就体现出来了。我们的处理方案是,在手工申请异步执行的方法实现中,为传入的异步操作加一层“包裹器”,例如下面这个API,它是用来给客户程序调用异步操作的,当时只是封装了线程池的简单调用,为的就是方便将来做扩展(例如我们可以改为Task来实现……)。

public static void SafeInvoke(Action action)
{
    ThreadPool.QueueUserWorkItem(o => action());
}

我们添加了一个扩展方法如下:

/// <summary>
/// 这里生成的wrapper会保证,在执行action前后,新开的线程和主线程都使用同一个Principel。
///
/// 解决问题:
/// 由于ApplicationContext.User是基于线程的,
/// 所以如果在同一次请求中,如果在服务端打开一个新的线程做一定的事情,
/// 这个新开的线程可能会和打开者使用不同的Principle而造成代码异常。
/// </summary>
/// <param name="action">
/// 可能会使用ApplicationContext.User,并需要在服务端另开线程来执行的操作。
/// </param>
/// <returns></returns>
public static Action AsynPrincipleWrapper(this Action action)
{
    if (ApplicationContext.ExecutionLocation == ApplicationContext.ExecutionLocations.Client)
    {
        return action;
    }
    var principelNeed = ApplicationContext.User;
    return () =>
    {
        var oldPrincipel = ApplicationContext.User;
        if (oldPrincipel != principelNeed)
        {
            ApplicationContext.User = principelNeed;
        }
        try
        {
            action();
        }
        finally
        {
            if (oldPrincipel != principelNeed)
            {
                ApplicationContext.User = oldPrincipel;
            }
        }
    };
}

原来的API改为:

public static void SafeInvoke(Action action)
{
    action = action.AsynPrincipleWrapper();
    ThreadPool.QueueUserWorkItem(o => action());
}

这样就实现了:手工打开的线程,使用和打开者线程相同的一个ApplicationContext.User。

小结

    本文主要介绍了如何把CSLA框架的服务端打造为支持多线程。可能会对使用CSLA框架的朋友会有所帮助。

    下一篇应用一个在GIX4项目中的实例,说明一下在具体项目中如何应用这几篇文章中提到的方法。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Bug生活2048

Python自学之路-Windows下配置SublimeText3问题汇总

今天在公司搭建SublimeText3下的Python环境,看来人品不行,安装过程中遇到些问题,这里汇总总结一下。

8510
来自专栏coder修行路

让你用sublime写出最完美的python代码--windows环境

 至少很长一段时间内,我个人用的一直是pycharm,也感觉挺好用的,也没啥大毛病 但是pycharm确实有点笨重,啥功能都有,但是有很多可能这辈子我也不会用到...

1.3K60
来自专栏草根专栏

Identity Server 4 - Hybrid Flow - Claims

前一篇 Identity Server 4 - Hybrid Flow - MVC客户端身份验证: https://www.cnblogs.com/cgzl/p...

13930
来自专栏吴伟祥

Shell脚本的认识 原

批处理(Batch),也称为批处理脚本。顾名思义,批处理就是对某对象进行批量的处理,通常被认为是一种简化的脚本语言,它应用于DOS和Windows系统中。批处理...

10220
来自专栏张善友的专栏

用psake来简化自动化脚本的构建

psake是一个集成了PowerShell的用来创建自动化脚本的工具,其2.01版本集成了PowerShell2.0。Ayende Rahien正使用它来创建R...

21650
来自专栏博客园

宿主

    ASP.NET Core应用程序需要在宿主中执行.宿主必须实现IWebHost接口,这个接口暴露了功能和服务的集合,以及Start方法。宿主通常使用We...

21130
来自专栏Jerry的SAP技术分享

使用SAP云平台的destination消费Internet上的OData service

通过SAP云平台上的destination我们可以消费Internet上的OData service或者其他通过HTTP方式暴露出来的服务。

41840
来自专栏林德熙的博客

Roslyn 如何基于 Microsoft.NET.Sdk 制作源代码包

本文告诉大家如何做源代码包,源代码包的意思是安装的包不是安装dll的方式,而是使用源代码的方式。也就是最后是编译包的源代码而不是添加dll,这个方式是解决想要把...

10720
来自专栏北京马哥教育

史上最全Linux服务器程序规范

作者:且飙丶且珍惜 来源: http://blog.csdn.net/dextrad_ihacker/article/details/51930998 除了网络...

41660
来自专栏性能与架构

体验 Mysql shell 控制台

以前登录Mysql的控制台后,使用SQL语言来操作数据库,如 mysql> select * from tablename; Mysql 5.7.12 之后有了...

388100

扫码关注云+社区

领取腾讯云代金券