У меня проблема с тем, как элемент управления ReportViewer использует SessionState.
Справочная информация: у нас есть приложение .NET 3.5 WebForms, которое использует ReportViewerControl в режиме RemoteServer.
Поскольку наше приложение использует инфраструктуру, которая требует SessionState (с использованием SQL Persistence), кажется, что элемент управления ReportViewer также подключается к SessionState.
Использование RV состояния сеанса проблематично:
- он сразу требует дополнительных 9 КБ сериализации (в dbo.ASPStateTempSessions)
- После отображения отчета все последующие страницы затем десериализуют состояние сеанса RV (т. е. каждую страницу, даже если на ней нет средства просмотра отчетов). Это включает сериализацию учетных данных, используемых для подключения к серверу SSRS.
В какой-то момент позже это неизбежно приводит к исключению rsExecutionNotFound после того, как SSRS очистит выполнение на своей стороне (срок выполнения отчета xyz истек или не может быть найден)
Как другие решили это довольно грубое поведение SessionState с помощью RV?
Текущее мышление состоит в том, чтобы вообще запретить RV использовать SessionState, например. создав отдельное приложение ASP для RV, а затем IFrame элемента управления RV в наше приложение.
В качестве альтернативы, есть ли способ уловить проблему десериализации SessionState и затем удалить ключи RV?
Любой совет серьезно оценен!
Изменить:
Проблема десериализации SessionState предположительно не возникает, если SessionState сохраняется в процессе с IIS.
С Fiddler во время десериализации SessionState наблюдается несколько подключений к SSRS, даже если страница не имеет элемента управления RV (предположительно, «сеттеры» для сериализованных объектов RV и учетные данные фактически повторно подключаются к SSRS)
Однако удаление ключей RV из SessionState при отображении на экране препятствует работе функций управления Ajax RV, таких как подкачка страниц (т. е. мы не можем просто собирать ExecutionId из RV и удалять их по мере их использования).
Единственное решение ATM состоит в том, чтобы реализовать «взлом», посредством которого ключи RV удаляются из SessionState на страницах, которые не имеют элемента управления RV (в надежде, что, если пользователь перейдет со страниц отчета, которые мы сможем очистить ДО SSRS timeout), а также перехватывать AspNetSessionExpiredException и ReportServerException в global.asax Application_Error, Abandon и Clear the Session и перенаправлять пользователя для входа в систему (в случае, если пользователь оставляет экран RV открытым и истекает время ожидания). К сожалению, удаление данных непосредственно из dbo.ASPStateTempSessions убивает наш собственный SessionState (отмечая, что как только SSRS истечет срок действия сеанса или удалит выполнение, SessionState больше не может быть десериализован)
Такое поведение наблюдается как в RV2008, так и в RV2010 (с SSRS 2008R2).
