autoeventwireup出问题（autoeventwireup出问题解决方法）

最近在写webform页面程序发现这样一个现象：在做导出功能时，由于导出数据的处理时间比较长，就在客户端加一个定时器通过ajax不间断查询导出进度。然后发现了一个情况，这个请求一直是阻塞的状态，直到导出事件处理完成之后。才去执行这个请求，也就是说如果响应时间长的请求还在进行中，短的请求却被挂起了。

百度了下，最终确定是asp.net session造成的。原文：https://www.cnblogs.com/littlewrong/p/4783104.html

原理：session实现了reader/writer的锁机制：

当页面对session具有可写功能（即页面有<%@page enablesessionstate=”true” %>标记），此时直到请求完成该页面的session持有一个写锁定。

当页面对session具有只读功能（即页面有<%@page enablesessionstate=”readonly” %>标记），此时知道请求完成该页面的session持有一个读锁定。

读锁定将阻塞一个写锁定；读锁定不会阻塞读锁定；写锁定将阻塞所有的读写锁定。这就是为什么两个框架中的同一个页面都去写同一个session时，其中一个要等待另一个（稍快的那个）完成后，才开始写。

“写锁定将阻塞所有的读写锁定”，也就是说页面在enablesessionstate=”true”的情况下没返回输出时，一直持着session写操作，其他页面对session的读操作必须等待，而asp.net的aspx页面默认是enablesessionstate=”true”，每个页面从请求开始至返回一直持着session写操作，需验证页面必须读取session值判断，这就是为什么需验证的页面请求被阻塞的原因。只要耗时页面（a页面）没有session的写操作，也就不会阻塞其他页面的请求，于是修改a页面的enablesessionstate=”readonly”，例如：<%@ page language=”c#” autoeventwireup=”true”codefile=”tbs_monitor_list.aspx.cs”enablesessionstate=”readonly” inherits=”tbs_monitor_list” %> ，问题解决。

结论：也就是说，在无需对session进行写操作的页面，在page指令加上enablesessionstate=”readonly”属性，就不会造成request阻塞的情况了。