По моему скромному IMHO, если уж так заботится о положительном впечатлении юзера от приложения, то надо пересмотреть сам подход к кешировании данных в сессии. Что я имею в виду.
Я предлагаю всю работу с данными, хранящимися внутри сессии, перенести в отдельный класс и работать только с ним (интерфейс можно сделать как и у Session). На событии Session_End сериализовать все данные, находящиеся там на текущий момент в постоянное хранилище (файлик, бд). Класс сделать singleton-ом, добывающим свой instance из текущей сессии и ложащий его туда в случае отсутствия (можно и просто Session_start обрабатывать). Внутри класса инкапсулировать всю логику проверки на наличие данных в сессии. При необходимости десериализовывать данные из постоянного хранилища. Предусмотреть различные стратегии сериализации-десериализации в зависимости от данных (к примеру, число можно и просто сохранить, а вот вместо датасета сохранить текст запроса к БД и получать его заново. Важные данные размещать в таблицах БД как часть основных данных приложения (та же самая корзина заказов из всех примеров :) )). В общем полный простор для полета фантазии :). И у юзера вообще не будет тогда проблем с протухшими сесиями. В любой (или почти в любой) момент времени он сможет продолжить работу с того места, где он остановился неделю назад.

Как идея?