最近在寫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阻塞的情況了。
原創文章，作者：投稿專員，如若轉載，請註明出處：https://www.506064.com/zh-tw/n/228041.html
微信掃一掃 
支付寶掃一掃 
