SqlSessionStateProviderAsync是否写入SQL库？如何验证会话配置有效性？

一、为什么ASPStateTempSessions/ASPStateTempApplications表无数据？ #

repositoryType="InMemoryDurable"模式的核心逻辑是先将会话数据存在Web服务器内存，再异步、定期同步至SQL数据库，并非实时写入。只有满足以下条件之一时，数据才会同步到SQL：

• 会话达到timeout设置的过期时间
• 调用Session.Abandon()主动销毁会话
• 内存中会话数据达到Provider内部触发同步的阈值

因此刚启动应用、未触发同步条件时，SQL表中无数据是正常现象。

二、验证Provider是否向SQL写入数据 #

1. 手动触发数据同步 #

• 调整Web.config中sessionState的timeout为1分钟：

  <sessionState mode="Custom" customProvider="SqlSessionStateProviderAsync" timeout="1">
    <!-- 其他配置项 -->
  </sessionState>
  

• 在应用中写入会话数据，比如：Session["TestData"] = "WebFarmTest"
• 等待1分钟以上，或直接调用Session.Abandon()
• 再次查询ASPStateTempSessions表，若出现对应会话记录，说明数据已成功写入SQL。

2. 检查配置正确性 #

确保Web.config的sessionState和Provider配置完全符合要求：

<sessionState mode="Custom" customProvider="SqlSessionStateProviderAsync">
  <providers>
    <add name="SqlSessionStateProviderAsync" 
         type="Microsoft.Web.SessionState.SqlSessionStateProviderAsync, Microsoft.Web.SessionState.SqlSessionStateProviderAsync"
         connectionStringName="ASPStateConnection" <!-- 确认连接字符串指向正确的ASPState数据库 -->
         repositoryType="InMemoryDurable" />
  </providers>
</sessionState>

• 确认mode为Custom，customProvider与Provider名称一致
• 验证连接字符串对应的账户拥有ASPState数据库的读写权限（至少分配db_datareader和db_datawriter角色）
• 确认已运行InstallSqlState.sql脚本创建ASPState数据库及相关表、存储过程（脚本路径通常为C:\Windows\Microsoft.NET\Framework\v4.0.30319\InstallSqlState.sql）

3. 查看系统事件日志 #

若Provider写入SQL失败，会在Windows事件查看器-应用程序日志中记录错误（如连接失败、权限不足等），可通过日志定位问题。

4. 启用Provider日志 #

在Web.config中添加诊断日志配置，记录Provider的操作细节：

<system.diagnostics>
  <trace autoflush="true" />
  <sources>
    <source name="Microsoft.Web.SessionState.SqlSessionStateProviderAsync" switchValue="Verbose">
      <listeners>
        <add name="SessionStateLog" type="System.Diagnostics.TextWriterTraceListener" initializeData="D:\Logs\SessionState.log" />
      </listeners>
    </source>
  </sources>
</system.diagnostics>

查看生成的日志文件，若存在AsyncSessionRepository相关的同步记录，说明Provider正在向SQL写入数据。

三、验证会话状态配置是否正常生效 #

1. 跨服务器会话一致性测试 #

• 关闭负载均衡的会话持久化策略（改为轮询模式）
• 在服务器A的应用中写入会话数据：Session["UserId"] = "12345"
• 手动切换到服务器B，读取Session["UserId"]，若能获取到12345，说明会话数据已通过SQL在服务器间同步，配置生效。

2. 检查会话ID一致性 #

同一用户在不同Web服务器上的会话ID应完全相同（内存会话模式下，会话ID是服务器本地生成，跨服务器会不同）。可通过在页面输出Session.SessionID验证。

3. 检查SQL代理作业 #

InMemoryDurable模式会自动创建SQL代理作业ASPState_Job_DeleteExpiredSessions用于清理过期会话。在SQL Server代理中查看该作业是否存在且正常运行，可确认Provider初始化正常。

4. 模拟SQL服务器故障 #

暂时断开Web服务器与SQL的连接，若应用仍能正常读取已存在的会话数据（存储在Web服务器内存中），符合InMemoryDurable模式“SQL故障时保持稳定”的特性，说明配置生效。

内容的提问来源于stack exchange，提问作者K Pilot