flexible, powerful Triggering logic

Ensuring Content Freshness

The primary technical challenge of any caching solution is accuracy; data in the cache must remain identical to data on the origin server at all times.  In-cache data that differs from origin server data is said to have expired. Data that is identical, by contrast, is said to be fresh.  The problem of assuring congruency between cached and origin server data is one of accurately recognizing when cached data expires so that the expired data can be refreshed with new origin server content.

By definition, dynamic content changes frequently.  In order for dynamic caching to operate effectively, the freshness of the data must be maintained on the basis of more than a time-based schedule – the traditional method for refreshing static content – but also when key application-specific events occur.    Warp’s SpiderCache addresses this challenge by providing the administrator with complete control over the recognition of, and reaction to, origin server content changes -- in many cases without requiring modifications to web site code. 

In contrast to other caching solutions that address dynamic content by effectively treating it as static and relying strictly on a time to live- (TTL) based cache refresh strategy, SpiderCache provides true dynamic content caching.   SpiderCache permits page elements to be refreshed either as a group or as a specific instance; site administrators enjoy complete control over caching expiration times and intervals, as well as through external events, which can be configured to invalidate the cache.

SpiderCache provides the administrator with four primary methods for identifying and reacting to expired data.  These are:

• Manual expiration
• Event-driven expiration
• Time-driven expiration
• Partial Page Caching

Manual Triggers

Manual commands can be sent to SpiderCache at any time to refresh either a specific page instance, or the entire cache.

Event Triggers

An administrator can use events to trigger cache expiration to maintain content freshness. Events can be triggered from a database, a URL, a content management system, or any other event that can be recognized and tracked.  For example, a change in the value of an item in the database can trigger cached page instances that depend on this data to be cleared from the SpiderCache cache. 

Event criteria in file’s cache configuration and settings can be easily be configured from within source code via the SpiderCache application-programming interface (API).  A news portal might, for example, dispatch an email whenever new data feeds arrive, prompting the cache for to clear specific page instances.   In addition, SpiderCache can clear an instance based on specific user events.  For example, a user clicking a Submit Bid button on an auction site could trigger the clearing of any page instance in the cache affected by this new bid.

As a courtesy to site administrators, SpiderCache ships with preconfigured stored procedure gateways for MS SQL Server and Oracle in Windows 2000 environments, and with Oracle in the Unix environment.  These procedure gateways ease the implementation effort for cache administrators, who do not need to start configuration from scratch.

Time Triggers

Like traditional static content caching solutions, a SpiderCache administrator can specify dynamic content to be refreshed based upon an elapsed time interval, such as five minutes.  

Structure Triggers