Browse Prior Art Database

A System and Method to Support User-Defined Prefetching.

IP.com Disclosure Number: IPCOM000201544D
Publication Date: 2010-Nov-15

Publishing Venue

The IP.com Prior Art Database

Abstract

Introduction/Abstract Disclosed is a System and Method to Support User-Defined Prefetching. A long-standing trend in enterprise information systems is the increased componentization for greater modularity, reusability, and better time-to-market. The components could be SOA services, widgets-based components (iWidget, yahoo! pipes, etc.), Object-oriented components, or proprietary components such as COM/DCOM. These components are often deployed in a distributed manner. Hence, the communication efficiency among these components varies with the network proximity of the involved components. Another trend is that a lot more data is being produced and shared than before. This is mainly due to the wide adoption of technologies such as sensors, visual monitors, and multimedia-on-demand that produce vast amounts of data very quickly. Hence, many of the above components serve as data providers, e.g., database query services, RSS feeds publishers, geographical map services, multimedia download services, and so on. Hence, communication in and across the information systems is often data-intensive. As a confluence of the above two trends, there is a need, much greater than before, to optimize the infrastructure that supports the communication among these components. In prior art, prefetching approaches are commonly proposed for (a) minimizing response times and (b) maximizing usage of the prefetched data. In (a), systems infrastructure such as parallel computing, priority-based network queues, and early predictions of the future data requests have been proposed. In (b), accurate prediction of the future data requests is proposed to ensure that the data prefetched is relevant in the future. However, in both (a) and (b) the designer of the application is not involved. Specifically, the system alone decides on what data to prefetch and when. Arguably, the designer of the component, having knowledge of the application domain, is in a better position to specify what data should be prefetched when a particular future request for data is predicted by the system with a varying degree of certainty. One reason for this is that the sequences of data requests are logically structured and follow patterns according to the business requirements they support. A component designer is privy to such logical patterns among the data requests and hence, can leverage this knowledge while choosing whether and how to prefetch. This disclosure proposes a novel solution that allows the component designer control over what data to prefetch, how to prefetch it, and how much of it to prefetch given that the system has predicted a future data request with a particular degree of certainty. In summary, allowing the component designers access to prediction information and control over the prefetching for serving future data requests is a largely unaddressed and yet an important issue.

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

Page 01 of 13

A System and Method to Support User -Defined Prefetching.

The following describes one possible way of implementing the ideas proposed earlier. The prediction method and the pattern identification modules below are quite simplified and are meant to provide a proof of concept only. A mature implementation would make use of the state-of-the-art prediction techniques and employ the latest research on identifying patterns in sequences of data.

An alternative way to implement the customised prefetching would be to let the system pass the parameters generated by the modules to the onPrefetch function at the runtime. The parameters would be received by the onPrefetch function and then it would prefetch the data according to the rules and logic defined by the component designer in the onPrefetch module. The structure of the overloaded onPrefetch would take the following form :

onPrefetch(Next

_

Event, Probability, Event

_Sequence)

{

. . .

}

onPrefetch(Next

_

Event, Time

_

Slice, Time

_Slice

_Counter))

{

. . .

}

Hence the proposed system and method is capable of handling customized prefetching both at the design time ( Using APIs) and at the runtime by passing the values of probability and its distribution as and when the state of the system changes.

BLOCK DIAGRAM OF THE PROPOSED SYSTEM AND METHOD

1



Page 02 of 13

(This page contains 00 pictures or other non-text object)

The proposed system and method consists of an Event Inference Manager (EIM) having the following modules:

1. Probability generator - Monitors data requests being triggered in the system by the various components and ased on the historical patterns repository, generates the probability of all future data requests. The predictions are updated at a regular time interval, e.g., one second.

2. Time-Varying probability distribution generator - For each predicted data requests from 1, generates the future time point at which the data request has

2



Page 03 of 13

the highest probability of occurrence. In addition, generates a discrete probability distribution around such a time point of the occurrence of the data request.

3. Historical patterns repository - Identifies patterns in the raw sequences of data requests and stores them in a repository, called Event Sequences and their occurrence frequencies (ESOF) and also the time of occurrence (TOC) which is a pointer to the time distribution table entry of that Event Sequence.

4. Prefetching Module - Integrates all the information provided by the other modules of EIM and notifies relevant components of the prediction parameters regularly. Also, implements the APIs for prefetching including prefetching proportional to the time varying probability of occurrence.

The Strucutre of Historical Patterns Repository

(This page contains 00 pictures or other non-text object)

PSEUDO-CODE OF THE COMPONENTS OF THE PROPOSED SYSTEM AND METHOD

1. The Probability Generator is a module that takes the current Event Sequence

3



Page 04 of 13

and searches in...