博客园_happyhippy

Asp.net 4.0，首次请求目录下的文件时响应很慢

2012-03-15T05:20:00Z

1. 问题起因
2. 尝试过的处理思路
3. 解决方法

1. 问题起因

一个从VS2003(.Net Framework 1.1)升级到.net framework 4.0的项目，每次编译或者部署到服务器上后，首次请求任何一个目录下的默认页面时，都要耗时3~5秒；而以前使用.net framework 1.1的时候，没有这个问题。

我在页面上开启Trace="true"来跟踪，发现页面的处理时间并不久(IIS重启，首次打开页面时截获的信息)：

但是IIS日志中，显示首次请求页面的耗时接近4.635秒。后续连续刷新页面，处理时间比较正常。。

虽然耗时比较久，但页面能够打开；然后我重启IIS，再次打开站点，用VS附加W3WP.exe来进行调试，再次打开这个页面的时候，发现抛出异常了：发生了 System.ArgumentException， Message=已存在具有相同键的条目。

   1: 发生了 System.ArgumentException   2:   Message=已存在具有相同键的条目。   3:   Source=System   4:   StackTrace:   5:        在 System.Collections.Specialized.ListDictionary.Add(Object key, Object value)   6:   InnerException:    7:     System.dll!System.Collections.Specialized.ListDictionary.Add(object key, object value) + 0x134 字节       8:      System.Web.dll!System.Web.UI.ParsedAttributeCollection.AddFilteredAttribute(string filter, string name, string value) + 0xba 字节       9:      System.Web.dll!System.Web.UI.TemplateParser.ProcessAttributes(System.Text.RegularExpressions.Match match, out System.Web.UI.ParsedAttributeCollection attribs = {System.Web.UI.ParsedAttributeCollection}, bool fDirective = false, out string duplicateAttribute = null) + 0x221 字节      10:      System.Web.dll!System.Web.UI.TemplateParser.ProcessBeginTag(System.Text.RegularExpressions.Match match = {System.Text.RegularExpressions.Match}, string inputText) + 0x68 字节      11:      System.Web.dll!System.Web.UI.TemplateParser.ParseStringInternal(string text, System.Text.Encoding fileEncoding) + 0x3d0 字节      12:      System.Web.dll!System.Web.UI.TemplateParser.ParseString(string text, System.Web.VirtualPath virtualPath, System.Text.Encoding fileEncoding) + 0x6f 字节      13:      System.Web.dll!System.Web.UI.TemplateParser.ParseFile(string physicalPath, System.Web.VirtualPath virtualPath) + 0x115 字节      14:      System.Web.dll!System.Web.UI.TemplateParser.ParseInternal() + 0x57 字节      15:      System.Web.dll!System.Web.UI.TemplateParser.Parse() + 0x64 字节      16:      System.Web.dll!System.Web.Compilation.BaseTemplateBuildProvider.CodeCompilerType.get() + 0x6f 字节      17:      System.Web.dll!System.Web.Compilation.BuildProvider.GetCompilerTypeFromBuildProvider(System.Web.Compilation.BuildProvider buildProvider) + 0x42 字节      18:      System.Web.dll!System.Web.Compilation.WebDirectoryBatchCompiler.CompileNonDependentBuildProviders(System.Collections.ICollection buildProviders) + 0xca 字节      19:      System.Web.dll!System.Web.Compilation.WebDirectoryBatchCompiler.Process() + 0x5d 字节      20:      System.Web.dll!System.Web.Compilation.BuildManager.BatchCompileWebDirectoryInternal(System.Web.Hosting.VirtualDirectory vdir, bool ignoreErrors) + 0x48 字节      21:      System.Web.dll!System.Web.Compilation.BuildManager.BatchCompileWebDirectory(System.Web.Hosting.VirtualDirectory vdir, System.Web.VirtualPath virtualDir, bool ignoreErrors) + 0xbc 字节      22:      System.Web.dll!System.Web.Compilation.BuildManager.CompileWebFile(System.Web.VirtualPath virtualPath = {System.Web.VirtualPath}) + 0x5d 字节      23:      System.Web.dll!System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(System.Web.VirtualPath virtualPath = {System.Web.VirtualPath}, bool noBuild, bool allowCrossApp, bool allowBuildInPrecompile, bool throwIfNotFound, bool ensureIsUpToDate) + 0x141 字节      24:      System.Web.dll!System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(System.Web.HttpContext context, System.Web.VirtualPath virtualPath, bool noBuild, bool allowCrossApp, bool allowBuildInPrecompile, bool throwIfNotFound, bool ensureIsUpToDate) + 0x70 字节      25:      System.Web.dll!System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(System.Web.VirtualPath virtualPath, System.Web.HttpContext context, bool allowCrossApp, bool throwIfNotFound) + 0x7e 字节      26:      System.Web.dll!System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(System.Web.VirtualPath virtualPath, System.Type requiredBaseType = {Name = "Page" FullName = "System.Web.UI.Page"}, System.Web.HttpContext context = {System.Web.HttpContext}, bool allowCrossApp) + 0x35 字节      27:      System.Web.dll!System.Web.UI.PageHandlerFactory.GetHandlerHelper(System.Web.HttpContext context, string requestType, System.Web.VirtualPath virtualPath = {System.Web.VirtualPath}, string physicalPath) + 0x20 字节      28:      System.Web.dll!System.Web.UI.PageHandlerFactory.System.Web.IHttpHandlerFactory2.GetHandler(System.Web.HttpContext context, string requestType, System.Web.VirtualPath virtualPath, string physicalPath) + 0x29 字节      29:      System.Web.dll!System.Web.HttpApplication.MapHttpHandler(System.Web.HttpContext context, string requestType, System.Web.VirtualPath path, string pathTranslated = "。。。。。。。。。。\\order\\default.aspx", bool useAppConfig) + 0xa8 字节      30:      System.Web.dll!System.Web.HttpApplication.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() + 0x81 字节      31:      System.Web.dll!System.Web.HttpApplication.ExecuteStep(System.Web.HttpApplication.IExecutionStep step = {System.Web.HttpApplication.MapHandlerExecutionStep}, ref bool completedSynchronously = true) + 0xb9 字节      32:      System.Web.dll!System.Web.HttpApplication.ApplicationStepManager.ResumeSteps(System.Exception error) + 0x13e 字节      33:      System.Web.dll!System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(System.Web.HttpContext context, System.AsyncCallback cb, object extraData) + 0xf8 字节      34:      System.Web.dll!System.Web.HttpRuntime.ProcessRequestInternal(System.Web.HttpWorkerRequest wr = {System.Web.Hosting.ISAPIWorkerRequestInProcForIIS7}) + 0x1a2 字节      35:      System.Web.dll!System.Web.HttpRuntime.ProcessRequestNoDemand(System.Web.HttpWorkerRequest wr) + 0x7d 字节      36:      System.Web.dll!System.Web.Hosting.ISAPIRuntime.ProcessRequest(System.IntPtr ecb, int iWRType) + 0xfd 字节      37:      [应用程序域转换]      38:      [本机到托管的转换]   

2. 尝试过的处理思路

我Attach到w3wp上去后，首次访问目录下的默认页面，catch到ArgumentException异常，然后根据异常信息，追踪到 TemplateParser.ParseFile -> ParseString -> ParseStringInternal -> ProcessBeginTag；然后我就尝试了下列努力：

1. 该目录下默认文件的<%@Page ....%>定义，属性与其他文件并没有任何不同(除了CodeBehind和Inherits的值)，我把页面里面的内容一点儿一点儿删掉，最后是剩下空内容(只剩下head、body、form几个元素)、空后台代码，问题还依旧存在。

2. 我在这个目录下面，新建了一个页面(VS2010自动生成的，没有添加任何元素或标签)，然后把这个新文件作为该目录默认页，发现问题还是存在。

3. 在第2步的基础上，打开新默认页后，我在URL中直接输入旧的默认页，页面瞬间刷出来了。然后我就纠结了，这延时，与页面内容毛的关系都木有，这异常信息也太坑爹了。

4. 出于尝试一下，我试下该目录下的其他文件，首次访问会不会变慢。于是重启IIS，然后发现首次访问该目录中的第一个文件(不论首次访问的是哪个文件)，都会耗时数秒；如果Attach到w3wp，都会Catch到这个异常。

5. 项目是从.net framework 1.1(VS2003)上直接升级过来的，以前03的版本，木有这个问题。然后google“asp.net 4.0 slow”，找到下面这个：

Slow Performance — ASP .NET ASPNET_WP.EXE and CSC.EXE Running After Clicking Redirect Link

6. The very first time that the page is load, then the asp.net compile a lot of pages, almost every one found on the same dir, including modules, and dlls found on bin.也就是说，在首次请求一个目录下的某个文件时，会把该目录的所有文件都编译一下。这样做的好处是，把一个目录的编译操作都集中在首次访问上，后续请求会比较快；但这样带来的问题是，如果编译时间比较久，那第一个发起请求的人就杯具了。于是在配置文件中，设置batch="false"，然后问题消失，首次请求的速度提上来了，attach上去也没有异常了。

3. 解决方法

部署的时候，记得在配置文件中，把debug和batch关闭，把optimizeCompilations打开：

标签: asp.net,Performance,compilation,batch,optimizeCompilations

本文链接

PageCollectionView[Bug]，使用Filter的时候，删除集合中的元素，会导致ArgumentOutOfRangeException

2012-03-02T03:16:00Z

PageCollectionView，没有使用Filter的时候一切正常；当使用Filter的时候，删除集合中的元素，会抛出如下异常：

   1: 指定的参数已超出有效值的范围。\n参数名: index      2: 位于 System.Windows.Data.PagedCollectionView.GetItemAt(Int32 index)\n      3: 位于 System.Windows.Data.PagedCollectionView.get_IsCurrentInSync()\n      4: 位于 System.Windows.Data.PagedCollectionView.AdjustCurrencyForRemove(Int32 index)\n      5: 位于 System.Windows.Data.PagedCollectionView.ProcessRemoveEvent(Object removedItem, Boolean isReplace)\n      6: 位于 System.Windows.Data.PagedCollectionView.ProcessCollectionChanged(NotifyCollectionChangedEventArgs args)\n      7: 位于 System.Windows.Data.PagedCollectionView.<.ctor>b__0(Object sender, NotifyCollectionChangedEventArgs args)\n      8: 位于 System.Collections.Specialized.NotifyCollectionChangedEventHandler.Invoke(Object sender, NotifyCollectionChangedEventArgs e)\n      9: 位于 System.Collections.ObjectModel.ObservableCollection`1.OnCollectionChanged(NotifyCollectionChangedEventArgs e)\n   位于 System.Collections.ObjectModel.ObservableCollection`1.RemoveItem(Int32 index)\n     10: 位于 System.Collections.ObjectModel.Collection`1.RemoveAt(Int32 index)\n    11: 位于 System.Collections.ObjectModel.Collection`1.Remove(T item)\n

搜了一圈，找到这篇：ArgumentOutOfRangeException in PageCollectionView

发现是PagedCollectionView的一个bug；更新到最新的SilverLight5，Bug依旧存在。没办法，只好从这里把PagedCollectionView的源代码抓下来，调整并重新编译：

   1: bool needToRemove = (this.PageSize == 0 && removeIndex >= 0) || (internalRemoveIndex >= 0 && internalRemoveIndex < (this.PageIndex + 1) * this.PageSize); 

记录一下。

本文链接

C#使用TCP/IP与ModBus进行通讯

2011-07-17T15:28:00Z

1. ModBus的 Client/Server模型
2. 数据包格式及MBAP header (MODBUS Application Protocol header)
3. 大小端转换
4. 事务标识和缓冲清理
5. 示例代码

0. MODBUS MESSAGING ON TCP/IP IMPLEMENTATION GUIDE

下载地址：http://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf

1. ModBus的 Client/Server模型

Client与Server之间有两种通讯方式：一种是TCP/IP，另一种是通过串口(Serial Port)，本文重点介绍第一种通讯方式。第二种方式留了接口，暂时还没有实现。

2. 数据包格式及MBAP header (MODBUS Application Protocol header)

2.1 数据包格式

    数据交换过程中，数据包的格式由三部分组成：协议头 + 功能码 + 数据(请求或接受的数据)。
    这里主要用到下列两个功能码（十进制）：
    3: 读取寄存器中的值（Read Multiple Register）
    16: 往寄存器中写值（Write Multiple Register）

2.2 MBAP header

协议头具体包括下列4个字段：
(1) Transaction Identifier：事务ID标识，Client每发送一个Request数据包的时候，需要带上该标识；当Server响应该请求的时候，会把该标识复制到Response中；这样客户端就可以进行容错判断，防止数据包发串了。
(2) Protocal Identifier：协议标识，ModBus协议中，该值为0；
(3) Length：整个数据包中，从当个前这个字节之后开始计算，后续数据量的大小(按byte计算)。
(4) Unit Identifier：-_-

3. 大小端转换

ModBus使用Big-Endian表示地址和数据项。因此在发送或者接受数据的过程中，需要对数据进行转换。

3.1 判断大小端

对于整数1，在两种机器上有两种不同的标示方式，如上图所示；因此，我们可以用&操作符来取其地址，再转换成指向byte的指针(byte*)，最后再取该指针的值；若得到的byte值为1，则为Little-Endian，否则为Big-Endian。

   1: unsafe   2: {   3:     int tester = 1;   4:     bool littleEndian = (*(byte*)(&tester)) == (byte)1;   5: }

3.2 整数/浮点数转换成Byte数组

.Net提供了现成的API，可以BitConverter.GetBytes(value)和BitConverter.ToXXOO(Byte[] data)来进行转换。下面的代码对该转换进行了封装，加入了Little-Endian转Big-Endian的处理（以int为例）：

   1: public class ValueHelper //Big-Endian可以直接转换   2: {   3:         public virtual Byte[] GetBytes(int value)   4:         {   5:             return BitConverter.GetBytes(value);   6:         }   7:         public virtual int GetInt(byte[] data)   8:         {   9:             return BitConverter.ToInt32(data, 0);  10:         }  11: }  12:    13: internal class LittleEndianValueHelper : ValueHelper //Little-Endian，转换时需要做翻转处理。  14: {  15:         public override Byte[] GetBytes(int value)  16:         {  17:             return this.Reverse(BitConverter.GetBytes(value));  18:         }  19:         public virtual int GetInt(byte[] data)  20:         {  21:             return BitConverter.ToInt32(this.Reverse(data), 0);  22:         }  23:         private Byte[] Reverse(Byte[] data)  24:         {  25:             Array.Reverse(data);  26:             return data;  27:         }  28: }

4. 事务标识和缓冲处理

4.1 Transaction Identifier

上面2.2节中提到，Client每发送一个Request数据包的时候，需要带上一个标识；当Server响应该请求的时候，会把该标识复制到Response中，返回给Client。这样Client就可以用来判断数据包有没有发串。在程序中，可以可以用一个变量及记录该标识：

   1: private byte dataIndex = 0;   2:     3: protected byte CurrentDataIndex   4: {   5:        get { return this.dataIndex; }   6: }   7:     8: protected byte NextDataIndex()   9: {  10:        return ++this.dataIndex;  11: }

每次Client发送数据的时候，调用NextDataIndex()来取得事务标识；接着当Client读取Server的返回值的时候，需要判断数据包中的数据标识是否与发送时的标志一致；如果一致，则认为数据包有效；否则丢掉无效的数据包。

4.2 缓冲处理

上节中提到，如果Client接收到的响应数据包中的标识，与发送给Server的数据标识不一致，则认为Server返回的数据包无效，并丢弃该数据包。

如果只考虑正常情况，即数据木有差错，Client每次发送请求后，其请求包里面包含需要读取的寄存器数量，能算出从Server返回的数据两大小，这样就能确定读完Server返回的所有缓冲区中的数据；每次交互后，Socket缓冲区中都为空，则整个过程没有问题。但是问题是：如果Server端出错，或者数据串包等异常情况下，Client不能确定Server返回的数据包(占用的缓冲区)有多大；如果缓冲区中的数据没有读完，下次再从缓冲区中接着读的时候，数据包必然是不正确的，而且会错误会一直延续到后续的读取操作中。

因此，每次读取数据时，要么全部读完缓冲区中的数据，要么读到错误的时候，就必须清楚缓冲区中剩余的数据。网上搜了半天，木有找到Windows下如何清理Socket缓冲区的。有篇文章倒是提到一个狠招，每次读完数据后，直接把Socket给咔嚓掉；然后下次需要读取或发送数据的时候，再重新建立Socket连接。

回过头再来看，其实，在Client与Server进行交互的过程中，Server每次返回的数据量都不大，也就一个MBAP Header + 几十个寄存器的值。因此，另一个处理方式，就是每次读取尽可能多的数据(多过缓冲区中的数据量)，多读的内容，再忽略掉。暂时这么处理，期待有更好的解决方法。

5. 源代码

5.1 类图结构：

5.2 使用示例

(1) 写入数据：

   1: this.Wrapper.Send(Encoding.ASCII.GetBytes(this.tbxSendText.Text.Trim()));   2:     3: public override void Send(byte[] data)   4: {   5:     //[0]:填充0，清掉剩余的寄存器   6:     if (data.Length < 60)   7:     {   8:         var input = data;   9:         data = new Byte[60];  10:         Array.Copy(input, data, input.Length);  11:     }  12:     this.Connect();  13:     List<byte> values = new List<byte>(255);  14:    15:     //[1].Write Header：MODBUS Application Protocol header  16:     values.AddRange(ValueHelper.Instance.GetBytes(this.NextDataIndex()));//1~2.(Transaction Identifier)  17:     values.AddRange(new Byte[] { 0, 0 });//3~4:Protocol Identifier,0 = MODBUS protocol  18:     values.AddRange(ValueHelper.Instance.GetBytes((byte)(data.Length + 7)));//5~6:后续的Byte数量  19:     values.Add(0);//7:Unit Identifier:This field is used for intra-system routing purpose.  20:     values.Add((byte)FunctionCode.Write);//8.Function Code : 16 (Write Multiple Register)  21:     values.AddRange(ValueHelper.Instance.GetBytes(StartingAddress));//9~10.起始地址  22:     values.AddRange(ValueHelper.Instance.GetBytes((short)(data.Length / 2)));//11~12.寄存器数量  23:     values.Add((byte)data.Length);//13.数据的Byte数量  24:    25:     //[2].增加数据  26:     values.AddRange(data);//14~End:需要发送的数据  27:    28:     //[3].写数据  29:     this.socketWrapper.Write(values.ToArray());  30:    31:     //[4].防止连续读写引起前台UI线程阻塞  32:     Application.DoEvents();  33:    34:     //[5].读取Response: 写完后会返回12个byte的结果  35:     byte[] responseHeader = this.socketWrapper.Read(12);  36: }

(2) 读取数据：

   1: this.tbxReceiveText.Text = Encoding.ASCII.GetString(this.Wrapper.Receive());   2:     3:         public override byte[] Receive()   4:         {   5:             this.Connect();   6:             List<byte> sendData = new List<byte>(255);   7:     8:             //[1].Send   9:             sendData.AddRange(ValueHelper.Instance.GetBytes(this.NextDataIndex()));//1~2.(Transaction Identifier)  10:             sendData.AddRange(new Byte[] { 0, 0 });//3~4:Protocol Identifier,0 = MODBUS protocol  11:             sendData.AddRange(ValueHelper.Instance.GetBytes((short)6));//5~6:后续的Byte数量（针对读请求，后续为6个byte）  12:             sendData.Add(0);//7:Unit Identifier:This field is used for intra-system routing purpose.  13:             sendData.Add((byte)FunctionCode.Read);//8.Function Code : 3 (Read Multiple Register)  14:             sendData.AddRange(ValueHelper.Instance.GetBytes(StartingAddress));//9~10.起始地址  15:             sendData.AddRange(ValueHelper.Instance.GetBytes((short)30));//11~12.需要读取的寄存器数量  16:             this.socketWrapper.Write(sendData.ToArray()); //发送读请求  17:    18:             //[2].防止连续读写引起前台UI线程阻塞  19:             Application.DoEvents();  20:    21:             //[3].读取Response Header : 完后会返回8个byte的Response Header  22:             byte[] receiveData = this.socketWrapper.Read(256);//缓冲区中的数据总量不超过256byte，一次读256byte，防止残余数据影响下次读取  23:             short identifier = (short)((((short)receiveData[0]) << 8) + receiveData[1]);  24:    25:             //[4].读取返回数据：根据ResponseHeader，读取后续的数据  26:             if (identifier != this.CurrentDataIndex) //请求的数据标识与返回的标识不一致，则丢掉数据包  27:             {  28:                 return new Byte[0];  29:             }  30:             byte length = receiveData[8];//最后一个字节，记录寄存器中数据的Byte数  31:             byte[] result = new byte[length];  32:             Array.Copy(receiveData, 9, result, 0, length);  33:             return result;  34:         }

(3) 测试发送和读取：

ModBus-TCP Client Tool（可以从网上下载，用来测试）中，可以点击“Edit Values”，修改寄存器中的值；然后再在测试程序中，点击“接收”，可以解析到修改后的值。这里只是测试发送和接收字符串，如果需要处理复杂的数字/字符串组合啥的，就需要自己定义数据格式和解析方式了。

5.3 代码下载

CSharpModBusExample

标签: ModBus,大小端,TCP/IP,Socket缓冲区

本文链接

ProtocolException : 已超过传入消息(65536)的最大消息大小配额。

2011-07-02T13:40:00Z

SilverLight调用WCF，提交的是一个List<Linq2SqlEntity>；当List中数据量不大的时候，不会报错；当数据量稍微大一点儿，就会出现这个错误。发生了 System.ServiceModel.ProtocolException
Message=已超过传入消息(65536)的最大消息大小配额。若要增加配额，请使用相应绑定元素上的 MaxReceivedMessageSize 属性。
Source=System.ServiceModel
StackTrace:
在 System.ServiceModel.Channels.HttpInput.ThrowHttpProtocolException(String message, HttpStatusCode statusCode, String statusDescription)

费了牛劲在网上搜了一通，有的说是要修改behavior的maxItemsInObjectGraph，有的说要修改binding的maxBufferSize/maxReceivedMessageSize，有的说要增加readerQuotas，有的是endpoint没有与自定义binding配置节关联起来，有的说要客户端和服务器端都要改(我的应用中，接受数据的是服务器端，客户端负责提交，所以应该不关客户端的事儿)。。。然后把server端的配置文件调整成下面这样：

   1: <system.serviceModel>   2:   <behaviors>   3:     <serviceBehaviors>   4:       <behavior name="MessageHeaderOperationBehaviourAuthenticationBehavior">   5:         <dataContractSerializer maxItemsInObjectGraph="2147483647"/>   6:         <serviceMetadata httpGetEnabled="true"/>   7:         <serviceDebug includeExceptionDetailInFaults="true"/>   8:       </behavior>   9:     </serviceBehaviors>  10:   </behaviors>  11:   <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true"/>  12:   <services>  13:     <service behaviorConfiguration="MessageHeaderOperationBehaviourAuthenticationBehavior"  14:              name="MessageHeaderOperationBehaviourAuthentication">  15:       <endpoint address="" binding="basicHttpBinding" bindingConfiguration="LargeSize" contract="DyeService">  16:       </endpoint>  17:     </service>  18:   </services>  19:   <bindings>  20:     <basicHttpBinding>  21:       <binding name="LargeSize"  maxBufferSize="2147483647"  22:                maxBufferPoolSize="21474836471" maxReceivedMessageSize="2147483647">  23:         <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"  24:                       maxArrayLength="2147483647" maxBytesPerRead="2147483647"  25:                       maxNameTableCharCount="2147483647" />  26:         <security mode="None" />  27:       </binding>  28:     </basicHttpBinding>  29:   </bindings>  30: </system.serviceModel>

但是问题依旧。最后在stackoverflow找到了正解：WCF Error - unexpected response: (400) Bad Request.，里面链接到了另一篇帖子：Cannot get the MaxReceivedMessageSize higher than (65536)

解决办法就是：配置文件中，service 的name属性必须与服务的类型全名称保持一致，才能应用上自定义的配置节。

按着这个方法，调整之后的配置文件如下所示（删掉了其他无关的maxItemsInObjectGraph、readerQuotas等）：

   1:     2:   <system.serviceModel>   3:     <behaviors>   4:       <serviceBehaviors>   5:         <behavior name="MessageHeaderOperationBehaviourAuthenticationBehavior">   6:           <serviceMetadata httpGetEnabled="true"/>   7:           <serviceDebug includeExceptionDetailInFaults="true"/>   8:         </behavior>   9:       </serviceBehaviors>  10:     </behaviors>  11:     <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true"/>  12:     <services>  13:       <service behaviorConfiguration="MessageHeaderOperationBehaviourAuthenticationBehavior"  14:                name="NameSpace.DyeService">  15:         <endpoint address="" binding="basicHttpBinding" bindingConfiguration="LargeSize" contract="NameSpace.DyeService">  16:         </endpoint>  17:       </service>  18:     </services>  19:     <bindings>  20:       <basicHttpBinding>  21:         <binding name="LargeSize"  maxBufferSize="2147483647"  22:                  maxBufferPoolSize="21474836471" maxReceivedMessageSize="2147483647">  23:         </binding>  24:       </basicHttpBinding>  25:     </bindings>  26:   </system.serviceModel>

标签: WCF,ProtocalException,65535,SilverLight

本文链接

ESC/P打印：程序控制打印机自动进退纸

2011-06-25T16:00:00Z

打印连续纸张的时候，经常会遇到需要自动进退纸的功能，譬如下列场景：
1. 打印完一个小标；(自动进纸)
2. 用户撕断打印出来的小标；
3. (自动退纸，纸张归位) 接着打印下一个小标；

下列代码在爱普生LQ 730k打印机上测试通过：

   1: //使用示例   2: new PrintDirect("PrinterName").PrintESC(1);//打印后进纸   3: new PrintDirect("PrinterName").PrintESC(0);//打印前退纸

源代码：

   1:     2:     [StructLayout(LayoutKind.Sequential)]   3:     public struct DOCINFO   4:     {   5:         [MarshalAs(UnmanagedType.LPWStr)]   6:         public string pDocName;   7:         [MarshalAs(UnmanagedType.LPWStr)]   8:         public string pOutputFile;   9:         [MarshalAs(UnmanagedType.LPWStr)]  10:         public string pDataType;  11:     }  12:    13:     public class PrintDirect  14:     {  15:         private string PrintPort { get; set; }  16:         public PrintDirect(string port)  17:         {  18:             this.PrintPort = port;  19:         }  20:    21:         [DllImport("winspool.drv", CharSet = CharSet.Unicode, ExactSpelling = false, CallingConvention = CallingConvention.StdCall)]  22:         public static extern long OpenPrinter(string pPrinterName, ref IntPtr phPrinter, int pDefault);  23:    24:         [DllImport("winspool.drv", CharSet = CharSet.Unicode, ExactSpelling = false, CallingConvention = CallingConvention.StdCall)]  25:         public static extern long StartDocPrinter(IntPtr hPrinter, int Level, ref DOCINFO pDocInfo);  26:    27:         [DllImport("winspool.drv", CharSet = CharSet.Unicode, ExactSpelling = true, CallingConvention = CallingConvention.StdCall)]  28:         public static extern long StartPagePrinter(IntPtr hPrinter);  29:    30:         [DllImport("winspool.drv", CharSet = CharSet.Ansi, ExactSpelling = true, CallingConvention = CallingConvention.StdCall)]  31:         public static extern long WritePrinter(IntPtr hPrinter, string data, int buf, ref int pcWritten);  32:    33:         [DllImport("winspool.drv", CharSet = CharSet.Unicode, ExactSpelling = true, CallingConvention = CallingConvention.StdCall)]  34:         public static extern long EndPagePrinter(IntPtr hPrinter);  35:    36:         [DllImport("winspool.drv", CharSet = CharSet.Unicode, ExactSpelling = true, CallingConvention = CallingConvention.StdCall)]  37:         public static extern long EndDocPrinter(IntPtr hPrinter);  38:    39:         [DllImport("winspool.drv", CharSet = CharSet.Unicode, ExactSpelling = true, CallingConvention = CallingConvention.StdCall)]  40:         public static extern long ClosePrinter(IntPtr hPrinter);  41:    42:         public void PrintESC(int type)  43:         {  44:             System.IntPtr lhPrinter = new System.IntPtr();  45:             DOCINFO di = new DOCINFO();  46:             int pcWritten = 0;  47:             di.pDocName = "进退纸Document";  48:             di.pDataType = "RAW";  49:    50:             try  51:             {  52:                 PrintDirect.OpenPrinter(this.PrintPort, ref lhPrinter, 0);  53:                 if (lhPrinter == IntPtr.Zero)  54:                 {  55:                     MessageBox.Show(string.Format("没有连接打印机或者打印机端口不是{0}！", this.PrintPort),  56:                         "提示", MessageBoxButtons.OK, MessageBoxIcon.Error);  57:                     return;  58:                 }  59:                 PrintDirect.StartDocPrinter(lhPrinter, 1, ref di);  60:                 PrintDirect.StartPagePrinter(lhPrinter);  61:                 string send = string.Empty;  62:                 for (int j = 0; j < 3; j++)  63:                 {  64:                     switch (type)  65:                     {  66:                         case 0:  67:                             send = "" + (char)(27) + (char)(64) + (char)(27) + 'j' + (char)(180);//退纸  68:                             break;  69:                         case 1:  70:                             send = "" + (char)(27) + (char)(64) + (char)(27) + 'J' + (char)(180);//进纸  71:                             break;  72:                         case 2:  73:                             send = "" + (char)(27) + (char)(64) + (char)(12);   //换行（未测试）  74:                             break;  75:                         default:  76:                             send = "" + (char)(27) + (char)(64) + (char)(12);   //换行（未测试）  77:                             break;  78:                     }  79:                     byte[] buf = new byte[80];  80:                     for (int i = 0; i < send.Length; i++)  81:                     {  82:                         buf[i] = (byte)send[i];  83:                     }  84:                     PrintDirect.WritePrinter(lhPrinter, send, send.Length, ref pcWritten);  85:                 }  86:             }  87:             catch (Exception e)  88:             {  89:                 MessageBox.Show(e.Message);  90:             }  91:             finally  92:             {  93:                 if (lhPrinter != IntPtr.Zero)  94:                 {  95:                     PrintDirect.EndPagePrinter(lhPrinter);  96:                     PrintDirect.EndDocPrinter(lhPrinter);  97:                     PrintDirect.ClosePrinter(lhPrinter);  98:                 }  99:             } 100:         } 101:     }

标签: ESC/P,打印,自动进纸,自动退纸

本文链接

判断泛型的值是否为default(T)

2011-06-21T15:00:00Z

   1: public static bool IsDefault<T>(this T value)    2: {   3:       //...   4: }

1. ==的问题

如果用==直接判断(default(T) == value)，编译时会提示错误：Error CS0019: 运算符“==”无法应用于“T”和“T”类型的操作数 (CS0019)。

2. object.Equals的问题

object提供了一个静态方法，可用于比较两个对象是否相等：

   1: public static bool Equals(object objA, object objB)   2: {   3:     if (objA == objB)   4:     {   5:         return true;   6:     }   7:     if (objA == null || objB == null)   8:     {   9:         return false;  10:     }  11:     return objA.Equals(objB);  12: }

但是该方法接收的是引用类型的实例，如果传入的是值类型(譬如int、enum、struct等)，则会对值类型进行装箱(boxing)。

3. EqualityComparer<T>.Default.Equals

最给力的方法，还是用EqualityComparer<T>.Default.Equals，

   1: public static bool IsDefault<T>(this T value)    2: {   3:      return EqualityComparer<T>.Default.Equals(value, default(T));    4: }

其实现了一个默认的比较器，可以比较Byte、Nullable<T>、Enum、Object、以及实现了IEquatable<T>接口(譬如int、bool、自定义类型等)的所有类型，可以用ILSpy来查看该类型的具体实现：

   1: private static EqualityComparer<T> defaultComparer;   2: public static EqualityComparer<T> Default   3: {   4:     [TargetedPatchingOptOut("Performance critical to inline across NGen image boundaries"), SecuritySafeCritical]   5:     get   6:     {   7:         EqualityComparer<T> equalityComparer = EqualityComparer<T>.defaultComparer;   8:         if (equalityComparer == null)   9:         {  10:             equalityComparer = EqualityComparer<T>.CreateComparer();  11:             EqualityComparer<T>.defaultComparer = equalityComparer;  12:         }  13:         return equalityComparer;  14:     }  15: }  16: [SecuritySafeCritical]  17: private static EqualityComparer<T> CreateComparer()  18: {  19:     RuntimeType runtimeType = (RuntimeType)typeof(T);  20:     if (runtimeType == typeof(byte))//其实byte也实现了IEquatable<Byte>，不知道为神马要把byte单独提出来？？？  21:     {  22:         return (EqualityComparer<T>)new ByteEqualityComparer();  23:     }  24:     if (typeof(IEquatable<T>).IsAssignableFrom(runtimeType))//如果类型实现了IEquatable<T>，则在运行时构造GenericEqualityComparer<T>，调用类型自身提供(重写)的equals方法。  25:     {  26:         return (EqualityComparer<T>)RuntimeTypeHandle.CreateInstanceForAnotherGenericParameter((RuntimeType)typeof(GenericEqualityComparer<int>), runtimeType);  27:     }  28:     if (runtimeType.IsGenericType && runtimeType.GetGenericTypeDefinition() == typeof(Nullable))  29:     {  30:         RuntimeType runtimeType2 = (RuntimeType)runtimeType.GetGenericArguments()[0];  31:         if (typeof(IEquatable).MakeGenericType(new Type[]  32:         {  33:             runtimeType2  34:         }).IsAssignableFrom(runtimeType2))  35:         {  36:             return (EqualityComparer<T>)RuntimeTypeHandle.CreateInstanceForAnotherGenericParameter((RuntimeType)typeof(NullableEqualityComparer<int>), runtimeType2);  37:         }  38:     }  39:     if (runtimeType.IsEnum && Enum.GetUnderlyingType(runtimeType) == typeof(int))  40:     {  41:         return (EqualityComparer<T>)RuntimeTypeHandle.CreateInstanceForAnotherGenericParameter((RuntimeType)typeof(EnumEqualityComparer<int>), runtimeType);  42:     }  43:     return new ObjectEqualityComparer<T>();  44: }

4. ILSpy比JustDecompile强大呀

4.1. ObjectEqualityComparer<T>.Equals方法的比较

4.2. EqualityComparer<T>.CreateComparer()方法：

各种杯具。。。

标签: default(T),IEquatable<T>,EqualityCompare

本文链接

T-SQL ROUND Function Bug?

2011-06-04T00:04:00Z

先看一个例子：

   1: DECLARE @Value float   2: SET @Value = 12.1785   3: SELECT '12.1785' as ValueToRound, ROUND(@Value,3) as RoundedValue   4: SET @Value = 12.1745   5: SELECT '12.1745' as ValueToRound,ROUND(@Value,3) as RoundedValue 

猜猜看，结果是多少？这个例子源自：T-SQL ROUND Function Bug

1. 问题起因

一个老系统，每个月要对系统发生的每笔业务数据进行汇总，生成应收款；但是每个月累计下来，总会与每天的连续累加汇总差(相差几分钱，或者几毛钱)。

同样的问题还有：仓库里面一批按重量计数的物资，每次出库的时候销账；但偶尔会出现：需要出库的数量，与库存中现有数量一致，但依然无法出库的情况。

问题的根源，就在于数据的存储类型。系统中，选择了使用float来存储数据。但计算机中，是使用近似值来表示float/double的，在这种+/-过程中，误差不断地累积，就出现了上述的这些问题。关于浮点数的存储格式，可以参考我之前的文章：“精确”判断一个浮点数是否等于0

2. Linq to SQL中的Round

知道了问题的原因，我们就可以针对性地进行处理：对数据进行四舍五入后再进行求和。

C#中，提供了两种控制四舍五入的计算方式：MidpointRounding.ToEven和MidpointRounding.AwayFromZero；默认为MidpointRounding.ToEven，即当一个数字是其他两个数字的中间值时，会将其舍入为最接近的偶数。有关舍入方式，可以参考MSDN：“MidpointRounding 枚举”。

值得一提的是，里面对MidpointRounding.AwayFromZero的翻译有误，翻译原文为：“AwayFromZero 当一个数字是其他两个数字的中间值时，会将其舍入为两个值中绝对值较小的值。”但英文原文为：“When a number is halfway between two others, it is rounded toward the nearest number that is away from zero.” 文档描述得相当糟糕，不知道是不是我理解能力太差，反正那一坨东西，绕来绕去，还是看里面举的例子比较靠谱。

   1: // 3.4 = Math.Round( 3.45, 1)   2: //-3.4 = Math.Round(-3.45, 1)   3:     4: // 3.4 = Math.Round( 3.45, 1, MidpointRounding.ToEven)   5: // 3.5 = Math.Round( 3.45, 1, MidpointRounding.AwayFromZero)   6:     7: //-3.4 = Math.Round(-3.45, 1, MidpointRounding.ToEven)   8: //-3.5 = Math.Round(-3.45, 1, MidpointRounding.AwayFromZero)

L2S中，如果直接用Math.Round(T.Amount, 2, MidpointRounding.AwayFromZero)，则解析成T-SQL就是直接调用Round函数；如果用Math.Round(T.Amount, 2, MidpointRounding.ToEven)，则会解析为：

   1: (CASE    2: WHEN ((([t0].[Amount]) * 2) = round(([t0].[Amount]) * 2, 2)) AND (([t0].[Amount]) <> round([t0].[Amount], 2)) THEN round(([t0].[Amount]) / 2, 2) * 2   3: ELSE round([t0].[Amount], 2)   4: END)

3. 解决方法

3.1 两次Round

使用一次Round可以解决小数点取舍问题，但无法处理浮点数精度带来的误差，下面是一次Round带来的结果：

这是因为，譬如浮点数2053.345在计算机内部存储的格式可能为2053.2449999999……，一次Round的结果就直接把后面49999…..的给舍掉了。但我们可以使用两次Round来达到需要的舍入效果：Round(Round(Value, 6), 2)

3.2 Decimal

处理精度问题，将数据类型定义为Decimal才是王道。

Decimal在计算及中的存储格式：Decimal 值长度是128位，由 1 位符号、96 位整数以及比例因子组成，比例因子用作 96 位整数的除数并指定整数的哪一部分为小数。比例因子隐式地定为数字 10 的幂，指数范围从 0 到 28。因此，Decimal 值的二进制表示形式为：((-2^96 到 2^96) / 10^(0 到 28))。比例因子还保留 Decimal 数字中的所有尾数零。

标签: Round,Decimal,Linq to Sql

本文链接

T-SQL 根据年月日创建DateTime

2011-05-28T02:36:00Z

T-SQL中提供了不少操作DateTime的函数，可惜竟然没有根据年月日创建DateTime类型的函数，例如DateTime(yyyy, MM, dd)这样的“构造函数”，杯具啊~~

   1: DECLARE @Year int, @Month int, @Day int;   2: SELECT @Year=2011, @Month=5, @Day=8;   3:     4: --法1：   5: SELECT CAST(CAST(@Year AS varchar(4)) + '-' + CAST(@Month AS nvarchar(2)) + '-' + CAST(@Day AS nvarchar(2)) AS DateTime)   6:     7: --法2：   8: SELECT DateAdd(dd, @Day-1, DateAdd(mm, @Month -1, DateAdd(yy, @Year - 1900, '19000101')))   9:    10: --法3：  11: SELECT DateAdd(mm, (@Year - 1900) * 12 + @Month - 1 , @Day - 1)

标签: DateTime,构造函数

本文链接

使用键值表实现通用流水号

2011-01-29T05:13:00Z

很多MIS系统，都需要用到流水号；一般的简单的流水号，由标识+日期+自增序号来组成；但如果考虑通用的话，就稍微复杂点儿的，需要考虑自定义日期格式、自增序号归1、自增序号溢出处理、前缀/中缀/后缀、并发访问、批量获取等，本文抽象出一个通用的生成流水号的方案。

1. 查询原始数据表 vs. 键值表
2. 键值表、取流水号的T-SQL实现
3. 并发处理需要考虑的三个因素
4. C#封装取流水号操作
5. 不给代码怎马叫给力~

1. 查询原始数据表 vs. 键值表

流水号的变动部分可分为日期和自增序号两部分，日期就是取当前的日期(yyyy、yyMM、或yyyyMMdd等)，自增序号部分可以有如下两种获取方式：

1.1. 每次查询原始数据表：

缺点就是要手工处理并发，如果并发量大的话，性能堪忧；好处就是每次可以取得准确的下一个自增序号，如果最后没有保存或者保存失败，取得的序号可以被重复读得，不会被浪费。

下面是一个并发示例：譬如当前表中最大的序号(这里暂时只考虑自增序号部分，忽略日期)为003，这是A/B两个用户同时打开页面并取得流水号，此时数据都没有保存，因此他们会取得相同的流水号004，保存时就会出现重复键值(违反唯一性约束)了。保险一点的做法，就是在保存的时候，去校验一下流水号是否已经被用过了；但是校验的时候，也必须十分小心，下面是一个保存时的未考虑并发的无效校验：

针对这个问题，一种解决办法就是，将操作串行化，保存前先获得锁：

可以在应用程序中加锁(但如果有集群的话，还要考虑多个服务器的问题)，或者锁数据库表。虽然加锁能解决并发问题，但是却带来更严重的性能问题。每次获取流水号时都要去查询原始数据表(或索引，如果有索引的话)，且插入前要进行加锁，操作只能被串行化，并发量一大，性能是个大问题。

1.2. 使用键值表

另一种思路就是使用键值表。可以为每个需要使用流水号的表，在键值表中保存一条记录，该记录保存其对应表中当前的最大流水号值。这样的操作的好处是：每次取流水号的时候，只需要操作该表中对应的一条记录即可，而不用去查询原始表/索引；还可以用于批量操作，一次获取一批流水号(批量录入或导入的时候，经常会用到)。

    键值表还需要处理的一个问题，何时更新键值表中的记录(当前最大值)？有两种处理思路：
    (1). 采用写时更新：能避免每次读取时查询原始表的问题，但还是会遇到上面1.1节中的并发问题。
    (2). 每次读取最大值的时候更新：先锁记录再读，最后更新为新的最大值。下一个人来读的时候，再取到下一个流水号，这样可以获得最大的并发性，但带来的问题是，如果上一个人取到的业务流水号最后没有保存，则这个流水号就废了(跳过去了)，导致最后的实际的业务流水号不连续。如果业务上允许序号被浪费，建议采用这种方式。

本文的解决方案，也主要是针对后一种(读取时更新)获取流水号的方式。

2. 键值表、取流水号的T-SQL实现

    还虑通用型，可以对业务流水号进行抽象：流水号 = 前缀+日期+中缀+流水号+后缀。
    其中：
    前缀/中缀/后缀：可以包含0个或多个字符；
    日期：可以包含yyMM、yyyy、yyMMdd、yyyyMMdd等多种格式；
    流水号：从1开始累加，按日期归1，长度可扩展(考虑到溢出)；
    这些信息都可以放在键值表中统一维护。

继续考虑通用性，可以封装下取流水号的操作，提供一个批量获取方式，一次取一批序号(Max + N)，避免批量操作时循环去取(Max + 1)；批量录入或导入的时候，经常会用到批量获取的方式。

2.1 键值表的设计

   1: /*happyhippy.cnblogs.com*/    2: IF(OBJECT_ID('SequenceNumber') IS NOT NULL)   3:     DROP TABLE SequenceNumber;   4:     5: Create Table SequenceNumber   6: (   7:     ID int identity(1,1),   8:     Code nvarchar(10) primary key,    /*Key*/   9:     Prefix nvarchar(5),   /*前缀*/  10:     DateType nvarchar(8), /*日期类型，可以为yyyy，yymm, yyyymm，yymmdd，yyyymmdd等等等等。*/  11:     Infix nvarchar(5),    /*中缀*/  12:     IndexLength int,      /*自增流水号长度*/  13:     Suffix nvarchar(5),   /*后缀*/  14:     MaxDate nvarchar(8),  /*当前最大日期值*/  15:     MaxIndex int default(0),/*当前最大流水号值*/  16:     CurrentMaxValue AS (Prefix + MaxDate + Infix + Replace(STR(MaxIndex, IndexLength), ' ' , '0') + Suffix)  17: )

    注意：
    (1). 表的主键设置在Code字段上；
    (2). MaxData、MaxIndex等记录当前最大值，用于直接运算。

2.2 T-SQL获取流水号

   1: /*happyhippy.cnblogs.com*/   2: go   3: IF(OBJECT_ID('GetSequenceNumber') IS NOT NULL)   4:     DROP PROCEDURE  GetSequenceNumber;   5:        6: go   7: CREATE PROCEDURE GetSequenceNumber   8: (   9:     @Code nvarchar(10),  10:     @Count int = 1  11: )  12: AS  13: BEGIN  14:     DECLARE @NewValue nvarchar(20), @CurrentDate nvarchar(8);  15:     DECLARE @Prefix nvarchar(5), @DateType nvarchar(8), @Infix nvarchar(5), @Suffix nvarchar(5);  16:     DECLARE @MaxIndex int, @IndexLength tinyint, @MaxDate nvarchar(8);  17:    18:     BEGIN TRAN  19:         --读取配置信息  20:         SELECT  @Prefix = Prefix, @Infix = Infix, @Suffix = Suffix,  21:                 @DateType = DateType, @MaxDate=MaxDate,  22:                 @MaxIndex = MaxIndex, @IndexLength = IndexLength  23:             FROM SequenceNumber with(xlock) WHERE Code=@Code;  24:           25:         --取得日期部分，如果需要其他格式，需要自己再扩展，增加CASE分支。  26:         SET @CurrentDate= SUBSTRING(Convert(nvarchar(8), GetDate(), 112),  27:             CASE SubString(@DateType, 1, 4)  28:                 WHEN 'yyyy' THEN 1  29:                 WHEN 'yyy' THEN 2  30:                 ELSE 3  31:             END, LEN(@DateType));  32:           33:         IF(@CurrentDate = @MaxDate)              34:             SET @MaxIndex = @MaxIndex + @Count; --累加  35:         ELSE  36:             SET @MaxIndex = @Count; --归1  37:           38:           39:         --超过自增长度限制，自动扩展自增部分的长度  40:         IF(@MaxIndex >= POWER(10, @IndexLength))   41:             SET @IndexLength = @IndexLength + 1;   42:           43:         --可以取消下面一行的注释，来测试并发  44:         --Waitfor delay '00:00:10';  45:               46:         Update SequenceNumber SET MaxDate = @CurrentDate, MaxIndex=@MaxIndex, IndexLength=@IndexLength WHERE Code=@Code;  47:     COMMIT TRAN  48:       49:     --取得获取到的最大值，取得@IndexLength和Len(@Suffix)用于解析得到批量获取的序列号  50:     SELECT (@Prefix + @CurrentDate + @Infix + Replace(STR(@MaxIndex, @IndexLength), ' ' , '0') + @Suffix), @IndexLength, Len(@Suffix);  51: END

    注意：
    (1). 整个读取、更新过程，封装在一次事务操作中；
    (2) 参数@Count，可以传一个正整数，批量获取多个流水号；
    (3). 第19~22行，读取的时候获取排它锁(xlock)，用于处理并发情况；
    (4). 第39~41行，如果溢出，则自动扩展自增序号的宽度；

3. 并发需要考虑的几个因素

    并发要考虑两种情况：
    (1) 并发访问同一种类的序列号(键值表中的一个Key)时，必须串行访问，以防止取得相同的流水号；
    (2) 并发访问不同种类的序列号(键值表中的不同Key)时，必须允许并发访问，互不干扰才能获得最大的并发度；

3.1 在应用程序中处理锁，还是在数据库中处理锁？

.Net中提供了现成lock、Monitor等，我们可以用来处理锁；譬如可以维护一个字典Dictionary<string, Object>，Key中保存键值表中对应的键值，Value保存同步对象，伪代码如下：

   1: private static object dictionarySyncObj = new object();   2: private static Dictionary<string, object> syncDictionary = new Dictionary<string, object>();   3: public static string GetMaxSequenceNumber(string key)   4: {   5:     lock (dictionarySyncObj)   6:     {   7:         if (!syncDictionary.ContainsKey(key))   8:         {   9:             syncDictionary.Add(key, new object());  10:         }  11:     }  12:     Object keySyncObj = syncDictionary[key];//针对不同的Key，使用不同的同步对象  13:     lock (keySyncObj)  14:     {  15:         //从数据库读取最大流水号....  16:         return ....  17:     }  18: }

程序中所有需要取流水号的地方，都调用该函数来获取，以保证对同一种类序列号的访问被串行化。如果系统只是部署在单台服务器上，这种方法没有问题；但是如果使用了服务器集群，系统在多个系统上部署了多份，则还是无法串行化对同一个Key的所有访问。

比较理想的做法，是在一个统一的地方处理并发，譬如在数据库中。上面第2节中，给出的键值表实现和获取流水号的存储过程，其实已经实现了并发处理，下面展开进行讨论。讨论之前，先执行下列代码来构造几个测试用例：

   1: /*构造测试用例*/   2: INSERT INTO SequenceNumber(Code, Prefix, DateType, Infix, IndexLength, Suffix)   3:     VALUES('Test1', 'P', 'yyyy', '', 8, ''),   4:         ('Test2', '', 'yymmdd', 'M', 6, ''),   5:         ('Test3', 'P', 'yymmdd', 'M', 6, 'S');   6:     7: UPDATE SequenceNumber SET MaxDate= SUBSTRING(Convert(nvarchar(8), GetDate(), 112),   8:             CASE SubString(DateType, 1, 4)   9:                 WHEN 'yyyy' THEN 1  10:                 WHEN 'yyy' THEN 2  11:                 ELSE 3  12:             END, LEN(DateType));

3.2 串行化访问同一种类的序列号

默认情况下(Read Committed事务隔离级别)，读取操作会对对应的数据Key(或行)加S锁(不考虑锁升级的情况)，对该行所属的页和表加IS锁；读取完毕后，就释放这些IS锁和S锁。可以加表提示(with (holdlock))，来让会话强制持有锁，直至事务结束(提交或回滚)后才释放锁。但是，如果多个会话并发访问的时候，由于IS锁与IS锁之间是兼容的，在值被更新(持有更新锁ulock)之前，可以并发读得相同的数据，因此这里读取时，必须要用排它锁(xlock)来独占资源，当一个线程读的时候，不允许其他线程并发读。有关并发和锁兼容性的更多介绍，可以参考我之前的文章《SQL Server死锁总结》。

可以取消2.2节中存储过程GetSequenceNumber中的第44行(Waitfor delay '00:00:10';)的注释，让T-SQL执行时等待10秒钟，以比较测试结果。开两个窗口分别同时执行下列一段测试代码：

   1: exec dbo.GetSequenceNumber 'Test2', 1;

第一个窗口的执行结果：

第二个窗口的执行结果(操作过程中存在延时，所以显示的只有18秒)：

虽然两个会话“同时”执行(第二个会话，我在操作时存在延时，所以显示的只有18秒)，但两个会话没有读得相同的序列号。执行时，第二个会话等待被阻塞等待了；只有等到第一个会话执行完毕后，第二个会话才获得锁资源，并继续执行；因此用了2倍的时间(20秒)。这就达到了多线程访问同一个Key时必须被串行化的效果。

3.3 并发访问不同种类的序列号

多线程并发访问不同种类的序列号(键值表中的不同Key)时，必须允许并发访问，互不干扰才能获得最大的并发度。在2.1节键值表的设计中，我将Code设为主键，这样做的一个好处，就是在读取一条Code记录并获取锁的时候，锁的粒度只会限制在Key锁，而不会升级为页锁或表锁。

现在开两个查询窗口，分别同时执行下列两段代码（注意：这次，两个窗口访问的是不同的Key）：

   1: exec dbo.GetSequenceNumber 'Test2', 1;

   1: exec dbo.GetSequenceNumber 'Test3', 1;

第一个窗口的执行结果：

第二个窗口的执行结果：

虽然两个会话同时执行，但是第二个会话，并没有被第一个会话阻塞，所以第二个会话也只用10秒就执行完毕了。两个会话可以并发执行，这就达到了多线程可以并发访问不同Key的效果。

如果执行上面的查询时，我们sp_lock来查看锁的情况，也可以看到：

参考我之前的文章《SQL Server死锁总结》，并结合上图，可以看到，两个X锁是应用在不同的Resource上，他们之间不会冲突；IX锁虽然应用在同一个Table上/Page(1:828)上，但IX锁与IX锁之间是兼容的，他们之间也不存在冲突；因此多个线程之间不会相互影响。回过头来考虑3.2节中的测试，两个会话尝试对同一个Key加X锁，但X锁与X锁之间是不兼容的，因此读取操作被串行化了。这里利用SQL Server的锁机制来实现并行化/串行化的目的。

抛一个问题，如果键值表的主键，不在Code字段上，还能并发访问不同种类的序列号吗？有兴趣的可以试试。

4. C#封装取流水号操作

   1: public static ReadOnlyCollection<string> GetSequenceNumbers(SequenceType type, int count = 1)   2: {   3:     string maxSequenceNumber = string.Empty;   4:     byte indexLength = 0;   5:     byte suffixLength = 0;   6:     //以上三个值，调用存储过程读取，省略。。。。   7:        8:     if (count == 1)   9:     {  10:         return (new List<string>() { maxSequenceNumber }).AsReadOnly();  11:     }  12:     else  13:     {  14:         string prefix = maxSequenceNumber.Substring(0, maxSequenceNumber.Length - indexLength - suffixLength);  15:         int index = Convert.ToInt32(maxSequenceNumber.Substring(prefix.Length, indexLength));  16:         string suffix = maxSequenceNumber.Substring(maxSequenceNumber.Length - suffixLength);  17:    18:         string format = "0000000000".Substring(0, indexLength);  19:         return Enumerable.Range(index - count + 1, count)  20:                     .Select(i => prefix + i.ToString(format) + suffix)  21:                     .ToList()  22:                     .AsReadOnly();  23:     }  24: }

使用方式：

   1: foreach (string item in SequenceNumber.GetSequenceNumbers(SequenceType.Test3, 3))   2: {   3:    Response.Write(item + "<br/>");   4: }

5. 不给代码怎马叫给力~

happyhippy.cnblogs.com.SequenceNumber.rar

参考文献：
《企业应用架构模式》

本文链接

[SilverLight]DataGrid实现批量输入(like Excel)（补充）

2011-01-12T12:33:00Z

更新内容：

1. Tab/Enter跳转到下一列；
2. 最后一行最后一列，Tab/Enter自动增加新行；
3. 增加新行后，自动跳转到新增行的第一列；
4. 删除行后，自动选中上一行；
5. Up/Down/Left/Right自动编辑；

实现方式：

1. Tab/Enter跳转到下一列

从google搜到的一篇文章《Datagrid cell navigation with enter key》，文中最开始提到在DataGrid的KeyDown事件中进行处理。但是DataGrid里面做了一些封装，我们在自己注册(通过+=操作符来登记、或者XAML中定义)的KeyDown事件中，截获不到Enter/Tab等键。所以最后原作者有提出一个思路：继承DataGrid，重新OnKeyDown方法。

但我之前的思路，是通过扩展方法来扩展DataGrid，再来重写就有点儿郁闷了。于是找出Reflector，翻了下DataGrid的实现(reflector中copy出来的)：

   1: // happyhippy.cnblogs.com   2: // 构造函数   3: public DataGrid()   4: {   5:     //省略   6:     base.KeyDown += new KeyEventHandler(this.DataGrid_KeyDown);   7:     base.KeyUp += new KeyEventHandler(this.DataGrid_KeyUp);   8:     //省略   9: }  10:    11: private void DataGrid_KeyDown(object sender, KeyEventArgs e)  12: {  13:     if (!e.Handled)  14:     {  15:         e.Handled = this.ProcessDataGridKey(e);  16:     }  17: }  18:    19: private bool ProcessDataGridKey(KeyEventArgs e)  20: {  21:     bool flag = false;  22:     switch (e.Key)  23:     {  24:         case Key.Tab:  25:             return this.ProcessTabKey(e);  26:    27:         case Key.Enter:  28:             flag = this.ProcessEnterKey();  29:             break;  30:    31:         case Key.Escape:  32:             return this.ProcessEscapeKey();  33:    34:         case Key.PageUp:  35:             flag = this.ProcessPriorKey();  36:             break;  37:    38:         case Key.PageDown:  39:             flag = this.ProcessNextKey();  40:             break;  41:    42:         case Key.End:  43:             flag = this.ProcessEndKey();  44:             break;  45:    46:         case Key.Home:  47:             flag = this.ProcessHomeKey();  48:             break;  49:    50:         case Key.Left:  51:             flag = (base.FlowDirection == FlowDirection.LeftToRight) ? this.ProcessLeftKey() : this.ProcessRightKey();  52:             break;  53:    54:         case Key.Up:  55:             flag = this.ProcessUpKey();  56:             break;  57:    58:         case Key.Right:  59:             flag = (base.FlowDirection == FlowDirection.LeftToRight) ? this.ProcessRightKey() : this.ProcessLeftKey();  60:             break;  61:    62:         case Key.Down:  63:             flag = this.ProcessDownKey();  64:             break;  65:    66:         case Key.Insert:  67:             return this.ProcessCopyKey();  68:    69:         case Key.A:  70:             return this.ProcessAKey();  71:    72:         case Key.C:  73:             return this.ProcessCopyKey();  74:    75:         case Key.F2:  76:             return this.ProcessF2Key(e);  77:     }  78:     if (flag && base.IsTabStop)  79:     {  80:         base.Focus();  81:     }  82:     return flag;  83: }

我们可以发现，KeyDown中已经定义一部分按键的处理，并更新了KeyEventArgs.Handled属性。MSDN对该属性的解释是：

将事件标记为已处理将会限制路由事件在事件路由过程中对于侦听器的可见性。事件将仍然进行路由过程的其余部分，但只会在响应中调用在 AddHandler(RoutedEvent, Delegate, Boolean) 方法调用中明确添加的其 HandledEventsToo 为 true 的处理程序。将不会调用实例侦听器上的默认处理程序（比如用可扩展应用程序标记语言 (XAML) 表示的那些处理程序）。处理标记为已处理的事件这种情形并不常见。

如果您是定义您自己的事件的控件作者，则您在类级别所做的有关事件处理的决策将影响您的控件的用户，以及派生控件的任何用户，并可能会影响您的控件所包含或包含您的控件的其他元素。有关更多信息，请参见将路由事件标记为“已处理”和“类处理”。

在极少数情况下，适合处理其中 Handled 标记为 true 的事件，并通过将 Handled 更改为 false 来修改事件参数。在控件输入事件的某些区域（比如 KeyDown 与 TextInput 键处理）中，低级别和高级别的输入事件会争用处理，并且每个事件都会尝试使用不同的路由策略，因此，可能必须要这样做。

也就是说，在将KeyEventArgs.Handled，我们通过+=来自己注册的处理程序，就无法执行了。一种替代思路就是在不要用+=来注册处理程序，而是调用AddHandler(RoutedEvent, Delegate, Boolean) 方法来注册处理程序：

   1: //之前的处理方式，将监听不到已经处理过的Tab/Enter等键   2: //dataGrid.KeyDown += KeyDownHandler<T>; //注册按键事件   3: //只能通过下列方式来注册   4: dataGrid.AddHandler(DataGrid.KeyDownEvent, new KeyEventHandler(KeyDownHandler<T>), true);

但在使用的时候发现，如果当前Cell(TextBlock)处于编辑状态，要按两次Tab/Enter才能跳转到下一列：第一次提交更改，第二次才执行跳转操作。

回过头来看，上面的DataGrid的部分源码，跟进去看了下KeyUp事件的处理，发现KeyUp并没有去更改KeyEventArgs.Handled属性。因此，我们可以考虑在DataGrid上注册自定义KeyUp事件，来做一些额外处理：

   1: dataGrid.KeyUp += KeyUpHandler<T>;   2:     3: private static void KeyUpHandler<T>(object sender, KeyEventArgs e) where T : class, new()   4: {   5:       DataGrid dataGrid = sender as DataGrid;   6:       switch (e.Key)   7:       {   8:              case Key.Tab:   9:                     goto case Key.Enter;  10:              case Key.Enter:  11:                     if (dataGrid.CurrentColumn != null)  12:                     {  13:                         if (dataGrid.IsLastRow() & dataGrid.IsLastCell()) // Last Row And Last Cell (End of the grid)  14:                         {  15:                             dataGrid.AddEntity<T>();  16:                         }  17:                         else if (dataGrid.IsLastCell()) // Last Cell  18:                         {  19:                             dataGrid.SelectedIndex = dataGrid.SelectedIndex + 1;  20:                             dataGrid.NextCellToEdit();  21:                         }  22:                         else // Normal navigation  23:                         {  24:                             dataGrid.NextCellToEdit();  25:                         }  26:                     }  27:                     break;  28:              default:  29:                     break;  30: }

2. 最后一行最后一列，Tab/Enter自动增加新行

能捕捉到Tab/Enter后，处理就比较简单了；只需判断时候在最后一行、最后一列，如果是，则调用上一篇文章中的增加新行方法：

   1: if (dataGrid.IsLastRow() & dataGrid.IsLastCell())   2: {   3:     dataGrid.AddEntity<T>();   4: }

3. 增加新行后，自动跳转到新增行的第一列

可以尝试在后台代码中，将DataGrid聚焦在新增行的第一列上：

   1: dataGrid.SelectedItem = entity;   2: dataGrid.CurrentColumn = dataGrid.Columns[0];   3: dataGrid.NextCellToEdit();

但是在实际使用过程中，可能会遇到如下异常：

这是因为，新增加的行，可能(有时能成功，有时可能失败)还没有来得及在UI显示出来，如果在这时设置SelectedItem/CurrentColumn，并调用ScrollIntoView，就会出现上面的异常。一种代替思路，就是用一个计时器来进行处理，如果执行失败，则下次接着执行，直到成功为止：

   1: public static void ScrolToFirstColumn(this DataGrid dataGrid, object entity)   2: {   3:     DispatcherTimer timer = new DispatcherTimer();   4:     timer.Interval = TimeSpan.FromTicks(100);   5:     object sucess = false;   6:     timer.Tick += (o, e) =>   7:     {   8:         if (!(bool)sucess)   9:         {  10:             dataGrid.SelectedItem = entity;  11:             dataGrid.CurrentColumn = dataGrid.Columns[0];  12:             dataGrid.NextCellToEdit();  13:             sucess = true;  14:             timer.Stop(); //执行完毕后，就不再执行。  15:         }  16:     };  17:     timer.Start();  18: }

4. 删除行后，自动选中上一行

默认情况下，行被删除行后，DataGrid没有选中任何行。如果想连续删除、或者用Up/Down/Left/Right跳转的话，就需要每次用鼠标点一下，着实不方便。于是提供了此功能：

   1: public static void DeleteCurrentRow(this DataGrid dataGrid)   2: {   3:     object entity = dataGrid.SelectedItem;   4:     IList dataSource = dataGrid.ItemsSource as IList;   5:     if (entity == null || dataSource == null || dataSource.Count == 0)   6:     {   7:         return;   8:     }   9:    10:     int selectedIndex = dataGrid.SelectedIndex; //删除前，记录当前行的位置  11:     if (ExtenderInfo[dataGrid].Deleteable)  12:     {  13:         dataSource.Remove(entity);  14:         dataGrid.SelectedIndex = selectedIndex - 1;//删除后，重置当前行  15:     }  16:     dataGrid.BeginEdit();  17:     ExtenderInfo[dataGrid].RaiseRowChangedEvent(dataGrid,  18:         new EntityChangedEventArgs() { ChangedEntities = new List<object> { entity }, Type = "Delete" });  19: }

5. Up/Down/Left/Right自动编辑

    上一篇文章中，通过在DataGrid的KeyDown事件中，见按键记录到DataGrid.Tag中，然后进入编辑状态时再赋值给单元格中的文本框(TextBox)，来实现即时编辑功能。但在使用的时候，发现如果使用中文输入法、或者列使用的是自定义模板列(不是TextBox)，就会遇到问题：
    如果是中文输入法+默认的TextBox：DataGrid会将第一个字符赋给TextBox，这样就多出一个字符，每次得多按一次BackSpace键。
    如果是使用自定义模板列，而不是TextBox，就会丢失第一次字符按键。

一种替代的思路，就是在捕捉Up/Down/Left/Right后，让DataGrid立即进入编辑状态。如上面第1点所述，还是要在KeyUp事件中进行处理。

6. 不给代码怎马叫給力

happyhippy.cnblogs.com.BatchInput.rar

本文链接