Browse Prior Art Database

Dynamic Result Set Invalidation/Refresh Within A Database Accelerator

IP.com Disclosure Number: IPCOM000240803D
Publication Date: 2015-Mar-04
Document File: 2 page(s) / 24K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a dynamic result set invalidation/refresh within a database accelerator. The method builds upon the value of a cached query and result set by allowing the result set to regenerate once the data that caused the invalidation has changed.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 2

Dynamic Result Set Invalidation /

In a database accelerator, a query and a result set for the query may be cached. When a change occurs to the source data that gave rise to the cached result set, this invalidates the cached result set. The query and result set may be discarded from the cache responsive to the invalidation.

A method is herein disclosed herein that recognizes value of the cached query and result set. Instead of discarding the cached query responsive to such an invalidation, the method selectively regenerates a new result set for the query, which may be done asynchronously, when processing capacity is available. Performing this asynchronous regeneration improves performance, because the processing delay of the initial query execution that led to caching the result set may be avoided the next time the query occurs. Thus, subsequent executions of the same common query can immediately benefit from the updated result set. The net result is for a potentially near-zero wait time for applications that reuse common queries for which data can change from time to time.

According to the disclosed method, a cached result set is discarded and the corresponding cached query is placed in a queue for processing responsive to invalidation, such as due to either a reload or change due to replication. If the accelerator has spare capacity, then a new task processes the queued requests utilizing spare capacity of the machine to re-execute the previously cached queries, thus regenerating the result sets. These asynchronous executions are considered discretionary. Therefore, if queries are received from other applications/users while regeneration is ongoing, the discretionary regeneration is terminated or postponed until spare processing capacity is available. This ultimately allows full utilization of the accelerator where it might be otherwise idle.

Additionally, if it occurs that the same query is received again during regeneration of a result set for the query, the discretionary regeneration is converted to nondiscretionary, so that the regeneration completes without waiting for spare processing capacity. Also, the regeneration is 'connected' to the incoming query, so that when it completes, the updated result set is not only cached but is also passed back to the application that sent the query. Thus, the incoming query is asynchronously 'jump started' due to the result set regeneration that was proceeding in the background.

Serviceability...