JAX技术有关。包含iframe,
frameset的页面已经要存取Session了,iframe或者frameset里面的页面也要存取Session,就有可能造成一先一后,都是同一个Session
ID,后面的页面被前面的页面锁住,直到前面的页面都处理完,释放对Session的锁,才能处理后面的页面。AJAX也类似。也存在这个
问题。这个默认的机制所带来的延迟在小型的ASP.NET应用中可以不用理睬。但是在大型的ASP.NET应用中是必须解决的问题。要解决这个问题,只能从应用的角度尽力减少需要写Session的范围,即明确确定哪些页面需要读且写Session数据。还需要确定哪些页面是只需要读Session数据。另外还需要确定哪些页面不需要参与读或者写Session数据,即与Session数据无关的页面。通过这样的
工作,就确定了Session的范围。对于需要读且写Session的页面,可以显示地在页面中写上<
% @Page enableSessionState=”On”% >。对于只需要读Session的页面,可以写上< % @Page
enableSessionState=”ReadOnly”% >。对于不需要Session的页面,可以写上< % @Page
enableSessionState=”Off”%
>。在一个iframe相关的所有页面中,不要所有的页面都去读写Session,这样就可以避免Session争锁所带来的延迟。AJAX所涉及的页面也是如此,尽可能地减少读写Session,发生这种Session争锁的延迟就会少一些。锁越少,整个UI排Tier的处理能力就会越大。
关于ViewState的技术方案
ViewState使服务器控件可以在往返行程中重新填充它们的属性值,而程序员不需要编写任何代码。这些属性值包括可见的属性,也包括不可见的。可见的属性如Text属性,不可见的是某些控件的ControlState。ControlState是比较特殊的内容,它总是存储在ViewState字段中。即使用EnableViewState="false"禁止了ViewState,ViewState字段还是有一些内容,这些内容就是ControlState。
曾经听到不少人抱怨说ViewState大,有时光ViewState就几百K。一个页面的
HTML,很大的部分是ViewState占用了。微软的文章也在说不需要ViewState的地方就禁止ViewState。所以合理决定应用程序哪些地方需要ViewState。毕竟ViewSate也一定程度上带给程序员一些方便。禁止ViewState是可以在整个应用的级别,页面的级别,和控件的级别来禁止。整个应用的级别禁止ViewState:
enableEventValidation="false">,页面的级别如:< % @
Page EnableViewState="false"
% >,控件的级别如:
xml:namespace prefix = asp />