Browse Prior Art Database

Method and System for Providing Application Specific Cache to Store Prepared Statements

IP.com Disclosure Number: IPCOM000235675D
Publication Date: 2014-Mar-19
Document File: 2 page(s) / 90K

Publishing Venue

The IP.com Prior Art Database

Abstract

A method and system is disclosed for providing application specific cache to store prepared statements. The method and system utilizes an application centric cache, independent of connections to store prepared statements and callable statements by utilizing common cache for multiple connections. Common cache for multiple connections reduces duplication and increases life cycle of cache depending on the state of the application.

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

Page 01 of 2

Method and System for Providing Application Specific Cache to Store Prepared Statements

Disclosed is a method and system for providing application specific cache to store prepared statements. The method and system utilizes an application centric cache, independent of connections to store prepared statements and callable statements by utilizing common cache for multiple connections. Common cache for multiple connections reduces duplication and increases life cycle of cache depending on the state of the application.

In the current implementation, an application requests for a connection. Further, a Connection Manager finds a free connection - 'Conn1' and provides the free connection to the application.

Figure 1

As shown in the figure 1, 'Application1' prepares a statement 'PreparedStatement1' using the connection 'Conn1'. A check is performed to determine if the prepared

statement already exists in the cache of Conn1. Since the prepared statement is a new statement, PreparedStatement1 is created. Then, Application1 executes the statement and closes PreparedStatement1. Thereafter, the statement is put to the cache of Conn1. Once the statement is put in the cache, Application1 closes the connection and Conn1 is released to 'Free Pool'. Subsequently, 'Application2' which runs a Structured Query Language (SQL) statement (different from Application1), calls get connection on connection factory and Conn1 (which is in the Free Pool) is returned. At the same time, a second thread goes through Application1 where

PreparedStatement1 needs to be executed. Therefore, application gets Conn2 (different connection) from pool as Conn1 is already in use. Again the

PreparedStatement1 is checked in Conn2's cache. Thus, there is duplicate and unutilized caching. Also, as the load increases, the same connections will be stored in newly created connections and the cach...