Browse Prior Art Database

A Navigation Method and System for On-demand Paging of Search Results in Applications on Application Servers Disclosure Number: IPCOM000020235D
Original Publication Date: 2003-Nov-04
Included in the Prior Art Database: 2003-Nov-04
Document File: 2 page(s) / 10K

Publishing Venue



Disclosed is a navigation method and system for on-demand paging of search results in applications on application servers to manage a very large result set from a query issued to the database, maximize performance and taking data consistency, scalability and session integrity into consideration.

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

Page 1 of 2

  A Navigation Method and System for On-demand Paging of Search Results in Applications on Application Servers

  This publication describes a method for reducing extraneous queries and building of HTML pages in an end-user query system. In our description, an LRU page table is used to manage some of the caching, however that cache is optional. The implementation can work with or without it. The following objectives are taken into consideration in the model: (1).The caching mechanism should improve the response time significantly. (2). The System must be scalable. (3). Data consistency. (4). Avoid displaying duplicate tuples that are generated because of location change. The caching mechanism has the following components: (1). Cache Control - Responsible for controlling cache operations (2). Cache Lookup - checks the availability of a cached page (a). Result set page table.(b). Locality page table.(c). LRU page table. (d). Result set page data cache (3). Cache transfer - When a page is found in the locality cache, the page mapping is transferred to the LRU cache. (4). Cache Replacement - select page victims for the replacement (5). Cache persistence - store pages in LRU cache to file system as static HTML pages or store in a database. (6). Cache Update - Update the cache (7). Data Consistency Check - When a page is displayed, every record that is to be displayed on the page will be looked for in the resultset_record_identifier table. If a corresponding record identifier entry is found in the table, only then the record is displayed.When a query is first executed, a list of pages that need to be pre-fetched or pre-paged is determined. The first two pages and the last page are always in the pre-fetch page list. Starting from page number 3, 'n' number of pages may also be candidates in the selected page list where 'n' is the size of the locality cache. The pages are retrieved from the database. The pages page-1, page-2 and the last page in the result set are stored in the result set page table, with a mapping between the page-number and the result-set data for the page which is a vector of hash tables. The page numbers that are computed as a working set are stored in a locality cache. The locality cache is a locality page table mapping between the locality page numbers and their corresponding page data sets. The locality page table page entries are added to the result set page table with the corresponding reference pointing to the locality page table. When a user requests a page, the cache control dispatches the request to the cache lookup. The cache lookup checks for the existence of the requested page number.

[Case-1]: If a page is found in result set cache and the page number is 1,2 or n.(where n is the last page) The corresponding result page data from the page number mapping is used by the Page Display Renderer to display the page.
If a page is found in the result set cache, and the reference refers to locality cache, then...