Lazy Tracking Web Cache Invalidation via Async Dirty Record Computation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In multi-tenant database systems, tracking changes to database objects for client-side web caching consumes significant computational and network resources, leading to increased overhead and potential system slowdowns as the system grows in size and complexity.
Innovation Solution
Implementing a lazy tracking mechanism that asynchronously computes and tracks dirty records for client-side caching, using a Client Record Subscription Map (CRSM) and Client Dirty Records Map (CDRM) to efficiently manage and transmit invalidation messages only when necessary.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the server tracks database objects and sends invalidation messages to user systems, then cache freshness is maintained, but computational and network resources are consumed
Solution Approach 1:
The server pre-computes and stores the mapping between database objects and subscribed user systems in a CRSM data structure before invalidation events occur. This preliminary organization allows O(1) lookup efficiency when invalidation messages need to be sent, avoiding the need to scan all user systems at invalidation time and reducing computational overhead.
Solution Approach 2:
The system changes the state of tracking from active continuous monitoring to lazy asynchronous computation. Invalidation messages are computed and sent only when necessary (when database objects change), rather than continuously tracking all changes for all users. This parameter change from continuous to event-driven tracking reduces overall computational resource consumption.
2Reliability
If the server sends invalidation messages to multiple user systems, then cache consistency is maintained, but network resources are consumed
Solution Approach 1:
The server merges multiple invalidation messages into a single batched message when multiple user systems need to be notified of the same database object changes. By combining notifications for multiple recipients into one network transmission, the total network resource consumption is reduced while still maintaining cache consistency across all user systems.
Solution Approach 2:
The system implements selective tracking where the server maintains CRSM and CDRM data structures that locally optimize the tracking information for each specific database object and user system combination. This local optimization ensures that invalidation messages are sent only to user systems that actually subscribed to specific database objects, avoiding unnecessary network transmissions to systems that don't need the updates.
3Reliability
If the server tracks database objects for multiple user systems, then cache invalidation is effective, but system overhead increases with growth
Solution Approach 1:
The system segments the tracking problem by creating separate CRSM (Client Record Subscription Map) and CDRM (Client Dirty Records Map) data structures that organize tracking information by user system and database object. This segmentation allows the server to manage tracking for multiple user systems independently and efficiently, reducing the complexity of managing global tracking state as the system grows.
Solution Approach 2:
The CRSM and CDRM data structures act as intermediary layers between the database objects and user systems. Instead of direct tracking relationships between each database object and each user system, the intermediary maps organize and manage these relationships systematically, reducing the overall system overhead for managing multi-tenant tracking.
Data Source
AI summary
Systems, methods, and computer-readable media for lazy tracking mechanisms for web caching systems are provided. The lazy tracking mechanism may track and perform asynchronous (async) computation of dirty records for client-side caching mechanisms. The async computation of dirty records may include tracking or accounting for invalidated records relevant to a particular client or user system. Invalidation messages may be sent to client/user systems in response to receipt of a request for updated records, or in response to a request for a particular item. Other embodiments may be described and/or claimed.


