Working with Cache Refresh (Pull or Polling Model)

Microsoft Commerce Server 2009 R2 caches frequently used data. This avoids frequent calls to the database and increases the overall speed and performance of a Web site.

While most organizations make changes to a Web site in a test environment and then move the changes to a production environment, some organizations may want to update their live Web site using either the business management tools, such as the Desktop Business Tools or the Commerce Server Business Administration Ribbon, or the Commerce Foundation application programming interface (API). As a result, the data in the cache becomes outdated and must be refreshed. If you intend to update data on a live Web site, you must enable cache refresh.

This topic covers the following:

  • Approaches to Refreshing Caches

  • Cache Refresh Workflow

  • Prerequisites for Cache Refresh

  • Tasks for Implementing Cache Refresh

Approaches to Refreshing Caches

Commerce Server 2009 R2 introduces a different approach to refreshing caches. Before Commerce Server 2009 R2, the servers refreshed their caches when they received a command to do so. This “push” method is still supported when Commerce Server 2009 R2 is deployed in a two-tier topology.

With the advent of the three-tier deployment architecture and the ability to cache data on both the presentation and application tier, each server in the deployment must check (poll) at regular intervals to determine if its cache is out of date. This “pull” or polling method is supported for both two-tier and three-tier deployments. It is the recommended method for refreshing caches.

Only data within a cache is refreshed; schema changes must still be refreshed by performing an IIS restart. See How to Restart IIS.

Cache Refresh Workflow

Using the business management tools, such as the Desktop Business Tools or the Commerce Server Business Administration Ribbon, the business user updates data on the live Web site and clicks a button or link in the user interface to request that all connected clients refresh their appropriate cache. Depending on the tool used to update the site, the Commerce Foundation operation service or a Commerce Server 2009 R2 Web service, for example, the Catalog Web service, receives the request and stores the request in a database table.

Both the application tier and the presentation tier employ a polling mechanism to query for pending cache refresh requests. On the application tier, the Commerce Foundation operation service queries for cache refresh requests at the interval specified in configuration and clears any affected caches. Subsequent data requests to the Commerce Foundation refill the cache with the latest information from the database.

On the presentation-tier, the Web application polls the connected Commerce Foundation operation service for pending cache refresh requests at the interval specified in configuration and clears the affected local caches. Subsequent data requests refill the cache with the latest information from the database. This means that a shopper who is viewing a page containing obsolete data will not see the changes when the cache on the server is cleared; however, the page is refreshed on the next request from the Web application to the Commerce Foundation.

In both cases, only those caches with data that has changed since the last polling are refreshed.

Prerequisites for Cache Refresh

The polling mechanism for detecting cache refresh requests aligns each server to the same even hour/minute/second polling times. This ensures that all servers connected to the same site check for cache refresh requests and clear stale caches in unison. This also reduces the probability that some servers have stale caches while others do not.

For example, if any Commerce Server 2009 R2 service, such as the Web application or Commerce Foundation operation service, starts up at 12:59:59, the polling mechanism will align its polling times to the nearest even hour/minutes/seconds:

Polling interval in seconds

Polling times

30

1:00:00, 1:00:30, 1:01:00, 1:01:30 …

60

1:00:00, 1:01:00, 1:02:00 …

20

1:00:00, 1:00:20, 1:00:40, 1:01:00 …

The following are prerequisites for synchronized cache refresh polling across all servers:

  • The time on all servers is synchronized.

  • The cache refresh polling interval is the same for all servers.

Implementing Cache Refresh

If you want business users to update data on a live Web site, you must enable cache refresh. Implementing cache refresh using the "pull" method involves the following tasks:

Task name

Description

Required

Modifying the Cache Refresh Configuration

Turn on presentation and application tier polling and adjust the polling interval

Yes

Configuring Authorization Security for the CommerceCache Entity

Specify the authorized identities that can perform update, query, or delete operations on the CommerceCache entity

Yes

Creating an HTTP Module for Presentation Tier Polling

Build a custom HTTP module to manage the presentation tier polling and cache refresh

Required for ASP.NET applications or SharePoint 2010 sites that were not built with the SharePoint Commerce Services Extensibility Kit

Using APIs to Manage Commerce Server Caches

Use the Commerce Foundation APIs to request a cache refresh, query for pending cache refresh requests, and clear caches

Required for ASP.NET applications, custom Solution Storefront sites, or custom cache refresh solutions

See Also

Other Resources

About the CommerceCache Entity

Overview of CommerceCache Operation Sequences

Using APIs to Manage Commerce Server Caches

Configuring Authorization Security for the CommerceCache Entity

Creating an HTTP Module for Presentation Tier Polling

Modifying the Cache Refresh Configuration