Browse Prior Art Database

Caching Java Connector for Legacy Data Stores

IP.com Disclosure Number: IPCOM000132070D
Original Publication Date: 2005-Dec-01
Included in the Prior Art Database: 2005-Dec-01
Document File: 5 page(s) / 122K

Publishing Venue

IBM

Abstract

This article describes a new method to allow faster access of legacy data formats by J2EE applications as well as on-line data. This is achieved through an innovative caching method where results of queries are cached in the converted format and when the queries are such that a whole record is cached in the new format, that record is persisted to a new data store directly from the cache.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 30% of the total text.

Page 1 of 5

Caching Java Connector for Legacy Data Stores

Problem

This article concerns the problem of data conversion from legacy mainframe systems, fast access, and porting to alternative formats.

Currently customers have much critical data in legacy VSAM data sets. However, mainframe skills are quickly being depleted while new development is geared towards emerging e-business technologies such as IBM's WebSphere. Rip & Replace approaches to move VSAM data to other platforms is prohibitively expensive in money and complexity. Also, it usually requires system down-time to allow migration. A Java connector exists which acts as a wrapper to the legacy data formats so that it can be accessed by web applications in a common format. The Java connector takes standard SQL queries and converts them to mine the legacy data and present it in the required forms. The problem is that using a simple connector means that the data, although accessible, it is slow and permanently remains in legacy form. However, by using a caching connector it will allow data to be served faster and provide data conversion into new format.

Outline Solution

The idea is to cache the data returned from the queries used by the Java Connector and persist the converted data to a separate data store. When the Java connector receives a request, it first checks its live cache. If the full record is found available in the cache then it will return the record to the caller. Thus minimizing input/output done on the mainframe system which free up processing time for other work to be done. However, if the record requested is found incomplete in the cache, the connector will call methods(described later) to modify the cache and depending on the request it can either return to the caller or perform input/output on the mainframe system to complete the cached record and return to the user. By doing this it helps minimizing I/Os done to the same queries next time around. In addition, during periods of low loads, a converter thread runs which constructs artificial queries. In this way, the legacy data is gradually converted to the new format during normal operation. While it is not guaranteed that all the data is converted within a period of time, the most commonly used data will be converted and stored in the new format very quickly while in periods of low workload, artificial requests could be run to access data which would probably not be accessed just by processing normal web requests.

Detailed Solution

Existing Architecture :

1

Page 2 of 5

VSAM JDBC Connector

This idea adds a control layer into the Resource Adaptor. The control layer has access to a cache and a new unpopulated data store, to which, ideally, the legacy data is reformatted and stored, as well as the JDBC connector. We describe how these components would work for query and write operations when dealing with a VSAM Key Sequenced Data Set. Transaction control and security management is handled by system contracts and is beyond...