InnovationQ will be updated on Sunday, May 20, from 10am - noon ET. You may experience brief service interruptions during that time.
Browse Prior Art Database

Aggressive Client-Side Cache Data Retrieval Agent Based on Usage Heuristics

IP.com Disclosure Number: IPCOM000196977D
Publication Date: 2010-Jun-22
Document File: 2 page(s) / 38K

Publishing Venue

The IP.com Prior Art Database


Disclosed is a method to use a heuristical data retrieval agent on the client side to aggressively retrieve more data than needed from the server to minimize the number of client server trips, but still maintaining data integrity semantics when the data is used in different transactions.

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

Page 1 of 2

Ȉ ˇ

In a distributed data store system (database, distributed cache, or other back-ends), clients request data remotely over the network. Response time is one of the most important performance metrics in such systems. In general, response time is affected by many factors, one of which is the number of client server trips. Obviously, for the same amount of data retrieved from the server to client, the more client server trips are involved, the more time it requires.

    In such a system, a client can access one or multiple records from the server using distributed APIs and/or commands. In a typical scenario, this distributed API or command is called within a transaction. The transaction uses data integrity mechanism to enforce transaction semantics. Several ways could be used to achieve data integrity, such as pessimistic locking or optimistic locking. In a pessimistic locking mechanism, the records are locked when sent to the client. In an optimistic locking mechanism, the resolution mechanism will be enforced at the transaction commit time to ensure data integrity.

    In some scenarios, the client might need to access a series of records, but they cannot decide the number of the records without the runtime knowledge. The typical solution is that the client uses a loop to get the data and use the runtime knowledge check as the loop condition. Obviously, the client can choose to get 1 record, 2 records, or 10 records in the loop for one client server trip.

    Let's assume the client gets 1 record in each loop. If the client finally ends up with getting 100 records from the server, there will be 2*100 client server trips (one for data retrieval, one for any data update at the end of transaction) involved.

Not only does the response time

Ȉ ˇ

Ȉ ˇ Ȉ ˇ

increase, but also it incurs overhead to the server.

    The solution to be disclosed here is to use a heuristic data retrieval agent to aggressively retrieve multiple records from the server. In each loop described above, the client actually retrieves N records from the server, although the client indicates it only needs 1 record. The number N is calculated based on the heuristics, which is based on client usage patterns. The number N could vary in each loop as a result of calculation. These N records are then dispatched to be used in different transactions. This solution decreases the number of client server trips. The disclosed method assures data integrity by employing an extended transaction control called transaction aliasing. The disclosed method includes the following major features:
1). Data Integrity - Transaction Aliasing

    To make the solution work, one needs to ensure the data integrity. This could be done by transaction aliasing. The transaction to get the N records is started by the agent, and is considered a master transaction T1. Then the data is dispatched to another transaction T2. T1 is considered an alias of T2. When T2 is committed, one coordinates T1 and T2 to make sure the...