New to Telerik Reporting? Start a free 30-day trial

REST Service Storage Overview

Updated on Aug 31, 2026

When configuring the REST Reporting Service, you must provide an IStorage interface implementation.

An instance of the provided implementation will be used by the service to store its internal state (like active clients, interactivity state, and rendered reports). The assets are serialized and saved as a key-value store.

The interface exposes a method called AcquireLock which is used by the service to enforce serialized access to all stored resources from each thread of the application, and between the instances of the application, in case of a multi-instance environment (i.e., Web Farm).

This requires selecting a suitable interface implementation when embedding the Reporting REST Service within your application.

Multi- and Single-Instance Support

The following implementations of the IStorage interface allow the service to support multiple instances.

MsSqlServerStorage - How to Configure an MSSQL Database Storage.

It supports storage server-side locks to achieve inter-machine resources serialized access through its Sql Server transactions feature.
RedisStorage - How to Use Redis storage.

It supports storage server-side locks to achieve inter-machine resources serialized access through its distributed locks feature.

Single Instance-Only Support

The following implementations of the IStorage interface support the service to be deployed as a single instance only.

For the locking mechanism, they use OS-specific synchronization primitives, which only enable inter-thread serialized access to resources within a single machine.

FileStorage - Use the FileStorage constructor to create a storage instance.

All Visual Studio item templates for adding the Reporting REST service use the default FileStorage constructor.

The second overload of the FileStorage constructor allows you to specify a folder, and it is recommended for use in a production environment.
DatabaseStorage - Use the DatabaseStorage constructor to create a storage instance.

This storage option requires a reference to Telerik.Reporting.Cache.Database.dll that has dependencies on Telerik Data Access, which can be checked in the version corresponding to the Upgrade article.

If one of those storages is used in a multi-instance(e.g., multiple PODs) environment, ensure that connections from a particular client are passed to the same Pod each time by configuring Session affinity(in other words - Sticky Sessions) based on the client's IP address.

Cleaning the Reporting REST Service Storage

Storage Contents

The REST Service Storage keeps all the information about the registered clients/viewers.

For example, the generated report documents, the images embedded in the reports, etc. Therefore, with each generated report, the occupied storage space increases.

Preventing Storage Size Increases

To prevent the storage from growing unnecessarily, when a client expires, the Reporting Service triggers a cleanup routine deleting its assets.

You can control the assets’ expiration using the ClientSessionTimeout and ReportSharingTimeout properties of the service configuration.

When a viewer is closed, there is no notification, and the service does not know about that. Therefore, periodically (every 5 minutes), the REST Service performs cleaning of the expired data. You can prevent the expiration of an active viewer by setting the viewer's option keepClientAlive to true (default).

The service triggers this logic only when awakened by a request from an active client/viewer.

Storage Structure

The assets cached when a report gets rendered are generated hierarchically, with each resource holding a reference to its parent resource.

To release a particular resource, the system counts the child resources that depend on this resource, and if there are none, it is considered expired and gets released.

Here are the resources from child to parent:

client session - Kept for ClientSessionTimeout minutes (15 by default) after the last request from the originating client. The client session keeps the requested document refreshes alive.
document refresh - A representation of the report document rendered at a particular moment in time. Contains the actual rendering assets like pages, images, and docs (for the export format). Keeps the originating report instance alive
report instance - this is the report definition with particular report parameter values, i.e., the report address.

Reusing Rendered Documents

You may reuse document refreshes by assigning the ReportSharingTimeout a positive value (the default is 0).

For example, when two clients request the same report with the same parameter values and states of its actions within ReportSharingTimeout minutes, the second client will reuse the document refresh created upon the first client's request.

Thus, there will be two clients holding a reference to this document refresh, and the latter will remain even if one of these clients expires.