Browse Prior Art Database

A Mechanism For More Efficient Loading Of Data From A Database Into A Cache By On-Demand Transfer Of The Needed Data From The Database Server To The JDBC Client

IP.com Disclosure Number: IPCOM000226485D
Publication Date: 2013-Apr-08
Document File: 3 page(s) / 29K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a mechanism to allow the most efficient Java Database Connectivity (JDBC) query, which is optimized for the local cache scenario. The mechanism only transfers the must-have data from the database to the JDBC client, while it transfers other fields from the server to the JDBC client upon first access.

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

Page 01 of 3

A Mechanism For More Efficient Loading Of Data From A Database Into A Cache By On-Demand Transfer Of The Needed Data From The Database Server To The JDBC Client

Most applications use Objects to represent business data. Operations and calculations are done on these Objects, while database tables permanently store the object states.

A lot programming model defines the Object to Database table mapping (e.g., Java* 2 Platform Enterprise Edition, Enterprise JavaBeans Contained-Managed Persistence, J2EE Java Persistence Application Protocol Interface). One method to improve performance is to cache objects loaded from a database close to applications, local cache, or partitioned in Data Grid. Therefore, as long as the objects in the cache are synchronized with the data stored in the database, interacting cached objects can reduce the database round trip and applications can have a much higher throughput and lower response time.

Figure: Current process for object loading

Most local cache systems store data as a key value pair, which can directly return an

object by key. However, it cannot efficiently handle the complex query that is needed to evaluate object fields. Usually, in order to make the query work with a system that has a local cache in front of the database, the query is executed in the database first to return the rows that satisfy the query condition. For each row, the primary key fields and a change token field are accessed first to create the primary object key and change token. The primary key is used to determine if the cache already has the object; the change token is used to evaluate whether the data in the cache is valid. Only when the cache does not have the object or the object data is already changed in the database (change token having a different value), is a new object created with the other fields' value in the query result. The new object is then put into cache for future use.

The problem with the above solution is that it leaves potential for a large amount of data to be retrieved from database that is never accessed because the object is already in the cache. For example, if a catalog object has 10 fields, when a query returns the

result of 50 rows, it returns all the 10 fields plus row change token data. However, as the catalog object is cached, the primary key fields and row change token fields need to first check with the cache to determine whether other fields of the catalog need to be pulled. As the catalog is seldom updated, most of the remaining nine fields do not need to be accessed; therefore, the extra nine fields of data passed from the database server to the Java Database Connectivity (JDBC) client are useless.

1


Page 02 of 3

If the user performs two queries, one to only retrieve the primary key and change token, then after evaluating the cache, the current system determines which objects need a reload to issue a second query with all the object-needed fields using the list of primary keys as cond...