Browse Prior Art Database

A method to design in-memory cache that represents the committed data in Database with transaction integrity

IP.com Disclosure Number: IPCOM000174784D
Original Publication Date: 2008-Sep-23
Included in the Prior Art Database: 2008-Sep-23
Document File: 2 page(s) / 20K

Publishing Venue

IBM

Abstract

This invention is to provide a simple and very light weight method to implement such in-memory cache with transaction integrity that can be adopted by software developer, especially in the Java programming language. This method does not need any involvement of transaction manager, XA protocol, does not have the limitation of multi-cache instances for the "last resource commit" method and can be code from the ground up.

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

Page 1 of 2

A method to design in-memory cache that represents the committed data in Database with transaction integrity

This invention will provide a simple and very light weight method to implement in-memory cache with transaction integrity. There are several assumptions: first, the program will get notifications before a transaction commits and after a transaction commits/abort/fails. This notification can be generated programmatically if developers manage their own transactions, or is readily available by the programming environment such as in J2EE/JTA environment. Secondly, we assume we can keep a complete list of changed data ID for a transaction. The second assumption is a bit restrictive, but can be easily achieved if a transaction will start and finish in one OS process or a JVM in Java. When there are multiple processes/JVMs participating in a transaction, it is still achievable by passing all the changed data ID when a transaction context is passed to another process/JVM.

With these two assumptions, here is a method of implementing the cache. Suppose in our cache we have a main data structure "HashMap mainMap" to hold all the cached data. When a program thread needs a data with ID1, it goes to the "mainMap.get(ID1)". This invention introduces a data structure in the cache to hold all the data that is in "transaction doubt" state. When in this state, the cached item cannot be used and worked as if the item is not cached so the calling thread has to go to the DB to retrieve the data. When a transaction tries to change ID1, we will put this ID1 into the transaction DoubtMap.

OnChange(Key k) {

"transactionDoubtMap.add(ID1)";

}

When other threads try to acce...