远程 SSRS 服务器模式下的 ReportViewer 控件和 SQL SessionState
我对 ReportViewer 控件使用 SessionState 的方式有疑问。
背景：我们有一个.NET 3.5 WebForms应用程序，它在RemoteServer模式下使用ReportViewerControl
由于我们的应用程序使用需要SessionState的框架（使用SQL持久性）， 看来 ReportViewer 控件也挂接到 SessionState 中。
RV 对会话状态的使用是有问题的：
- 它立即需要额外的 9k 序列化（在 dbo.ASPStateTempSessions 中）。
- 显示报告后，所有其他页面都会反序列化 RV 会话状态（即每个页面，即使它没有报表查看器）对其进行控制） 这包括用于连接到 SSRS 服务器的凭据的序列化。
在稍后的某个时刻，一旦 SSRS 清理了其一侧的执行，这将不可避免地导致 rsExecutionNotFound 异常 （报告执行xyz已过期或找不到）
其他人如何解决RV这种相当粗鲁的SessionState行为？
当前的想法是完全阻止 RV 使用 SessionState，例如，通过为 RV 创建单独的 ASP 应用程序，然后将 RV 控件 IFrame 到我们的应用程序中。
或者，有没有办法捕获 SessionState 反序列化问题并删除 RV 的密钥？
任何建议都非常感谢！
编辑：
如果 SessionState 保留在 IIS 的 Process 中，则可能不会遇到 SessionState 反序列化问题。
使用 Fiddler，在 SessionState 反序列化期间，即使页面没有 RV 控制，也会观察到与 SSRS 的多个连接（大概是序列化 RV 实体和凭据上的“setters”实际上重新连接到 SSRS）
。屏幕上的 SessionState 会阻止 Ajax RV 控制功能（例如分页）工作（即我们不能只从 RV 收集 ExecutionId 并在使用时将其删除）。
唯一的解决方案 ATM 是实现“黑客”，从而将 RV 密钥从没有 RV 控件的页面上的 SessionState 中删除（希望如果用户离开报告页面，我们可以在 SSRS 之前清理）超时），并在 global.asax Application_Error 中捕获 AspNetSessionExpiredException 和 ReportServerException，放弃并清除会话，并重定向用户登录（如果用户保持 RV 屏幕打开并且超时）。不幸的是，直接从 dbo.ASPStateTempSessions 删除数据会杀死我们自己的 SessionState（注意，一旦 SSRS 使会话过期或删除执行，SessionState 就无法再反序列化）
在 RV2008 和 RV2010（使用 SSRS 2008R2）中都观察到此行为
I have an issue with the way the ReportViewer Control uses SessionState.
Background : We have a .NET 3.5 WebForms App, which uses the ReportViewerControl in RemoteServer mode
As our application uses a framework that needs SessionState (using SQL Persistence),
it seems the the ReportViewer control also hooks into SessionState.
RV's use of session state is problematic:
- it immediately takes an additional 9k of serialization (in dbo.ASPStateTempSessions)
- After displaying a report, all further pages then deserialize the RV session state (i.e. every page, even if it doesn't have the reportviewer control on it)
This includes serialization of the credentials used to connect to the SSRS server.
At some point later, this inevitably leads to a rsExecutionNotFound exception once SSRS has cleaned up the execution on its side
(The report execution xyz has expired or cannot be found)
How have others solved this rather rude SessionState behaviour by RV?
Current thinking is to prevent RV from using SessionState at all, e.g. by creating a separate ASP Application for RV and then IFrame the RV control into our app.
Alternatively, is there a way to trap the SessionState deserialization issue and remove RV's keys then?
Any advice seriously appreciated!
Edit:
The SessionState deserialization issue presumably isn't encountered if the SessionState is kept in Process with IIS.
With Fiddler, during SessionState deserialization, several connections to SSRS are observed, even if the page doesn't have the RV control (presumably the 'setters' on the serialized RV entities and credentials actually reconnect to SSRS)
However, removing the RV keys from SessionState while on screen prevents the Ajax RV control functionality such as paging from working (i.e. we can't just collect ExecutionIds from RV and remove them as they are used).
Only solution ATM is to implement a 'hack' whereby the RV keys are removed from SessionState on pages which don't have the RV Control (in the hopes that if the user navigates away from the Report pages that we can clean up BEFORE the SSRS timeout), and to trap AspNetSessionExpiredException and ReportServerException in global.asax Application_Error, Abandon and Clear the Session, and redirect user to login (in the event of the user leaving the RV screen open and timing out). Unfortunately, deleting data directly from dbo.ASPStateTempSessions kills our own SessionState (noting that once SSRS expires the session or deletes the execution that the SessionState can no longer be deserialized)
This behaviour is observed in both RV2008 and RV2010 (with SSRS 2008R2)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论