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)