Reporting Services has a notion of a user session.  This is not the same as ASP.Net's notion of a user session, and in fact the two are completely orthogonal to each other.  SSRS's session maintains information about which report a user is looking at, the data that is in that report (we call this a snapshot), the interactivity state (what items are shown/hidden), parameter state, etc...  These sessions are aged out based on the last time they were accessed.  For most scenarios where you use the viewer control, you should never have to worry about sessions because it will automatically ping the SSRS web server to keep the user's session alive. 

However, there is one scenario where the ping doesn't work, and that is during the inital report execution.  The problem is that while the report is being executed, the user's session is locked (as we are populating the user's temporary snapshot) and the keepalive from the viewer control will be blocked.  Normally, this is not a problem because report executions aren't supposed to take a long time and quite often they finish before the session timeout hits.  Unfortunately, there are some cases where reports (for whatever reason) take an incredibly long time to execute.  What happens in this case is that the user's session is aged out while the report is being executed, resulting in all sorts of strange behavior. 

Fortunately, there exists a couple of solutions:

  1. Reduce the time it takes to run the report.  Generally this involves simplifying the report or moving some of the aggregation/sorting to the database layer (RDBMSs are generally better at this than we are). 
  2. Consider running the report offline.  Try creating a schedule by which the report is executed during off-hours, and users only see this snapshot of the data.  This can greatly improve execution performance for large reports which involve lots of grouping/sorting in the report server.
  3. Consider delivering the reports via a subscription.  Probably your user doesn't want to leave IE sitting open for two hours waiting for a report to render.  It is too easy to accidently close the window and now he or she is back at square one.  If you have a report which takes hours to generate, consider creating a subscription and delivering the report to the person via email or a file share.

If none of these solutions really work for you, then as a last resort you can modify the SessionTimeout and SessionAccessTimeout system properties.  You should configure these values to be no less than the time it takes to render your largest report.  Here is a sample script for rs.exe which will set these values for you: 

 



   
     

    
      
    
      Public
    
       
    
      Sub
    
       Main() 
    
      Dim
    
       props() 
    
      as
    
       [
    
      Property
    
      ] props 
    
      =
    
       
    
      new
    
       [
    
      Property
    
      ] () { 
    
      new
    
       [
    
      Property
    
      ](), 
    
      new
    
       [
    
      Property
    
      ]() } props(
    
      0
    
      ).Name 
    
      =
    
       
    
      "
    
      SessionTimeout
    
      "
    
       props(
    
      0
    
      ).Value 
    
      =
    
       timeout props(
    
      1
    
      ).Name 
    
      =
    
       
    
      "
    
      SessionAccessTimeout
    
      "
    
       props(
    
      1
    
      ).Value 
    
      =
    
       timeout rs.SetSystemProperties(props) 
    
      End Sub

 

You can run this script with the following command:



   
     

    
      
    
      rs -i sessionTimeout
    
      .
    
      rss -s http:
    
      //
    
      localhost
    
      /
    
      reportserver -v timeout
    
      =
    
      "
    
      6000
    
      "

The timeout is expressed in seconds, so this example sets the SessionTimeout and SessionAccessTimeouts to about an hour and a half.  Note that you should do this with caution, keeping a session around longer than necessary can cause your ReportServerTempDB database to grow larger since temporary session snapshots will not be aged out as often.

[http://blogs.msdn.com/jgalla/archive/2006/10/11/session-timeout-during-execution.aspx]