ADOMD.NET - Microsoft SQL Server 2008 Analysis Services - page 612

a single level from a single hierarchy). In reality, however, most client applications eventu-
ally iterate an object hierarchy touching almost all the metadata objects.

ADOMD.NET has a special caching mechanism to decrease the number of round trips
between client and server. Caching occurs only on objects that are frequently used and do
not demand huge memory consumption, such as dimensions, hierarchies, and levels.

We do not apply caching to members because doing so can entail loading a huge quantity
of information that probably would not be used. Neither do we cache small collections of
measures, named sets, and key performance indicators (KPIs) because they are not often
used and may vary for each request to the server. For example, if a client application sends
a request to the server to create a calculated measure, the result of that request will change
the contents of MeasureCollection on the server. So, using MeasureCollection from the
cache would produce an incorrect response.

Here's how the caching of metadata works. The Cube Def object stores three data struc-
tures: one for all the dimensions in the cube, another for all the hierarchies of the cube,
and a third for all the levels of the cube. As soon as a client application requests the first
dimension of a cube, all the dimensions are requested. When it requests the first hierar-
chy, all the hierarchies are requested, and so on. ADOMD.NET stores data and relation-
ships between objects; the relationships help to define what hierarchy belongs to what
dimension, connecting them by the column DIMENSION_UNIQUE_NAME . Figure 33.10 shows
the structures that ADOMD.NET uses to cache metadata.

Dimensions Hierarchies Levels

FIGURE 33.10

ADOMD.NET caches metadata.

Unfortunately, while your query is running, another connection can update the cube on
the server. When this happens, the results returned from a cache will differ from the