Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1999-11-01
2002-08-13
Breene, John (Department: 2177)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000
Reexamination Certificate
active
06434543
ABSTRACT:
FIELD OF THE INVENTION
This invention relates to distributed object systems and, more particularly, to a system and method for managing connections between a client object and a database object in order to efficiently utilize the database.
BACKGROUND OF THE INVENTION
Software programs are continually becoming more complicated. Early programs consisted of straightforward procedural code that presented a simple, command line interface and text display to the user. These simple programs have gradually been replaced with complex programs that have graphical user interfaces and multiple features. As programs have grown in complexity, the amount of effort which is required to write and debug the programs has also increased drastically. Consequently, major efforts have been made to reduce the amount of programming necessary to produce a modern, full-featured product. One of the most successful of these efforts has been the development of object-oriented programming in which programs are designed as collections of discrete elements called “objects”. The objects can be modified and re-used in many cases, thereby reducing the development effort.
As will be understood by those skilled in the art, objects in the context of object-oriented programming are software entities comprising data and methods or operations on that data. The methods of an object collectively form an interface for manipulating the data in the object. The objects exist only at program runtime and are created, or instantiated, from object “classes” which are actually written by the programmer. The class code written by a programmer can be “reused” by another programmer by instantiating objects from that code.
In order to further reduce the programming burden, distributed object systems have been developed in which methods in objects resident on a server can be executed or invoked remotely over a network from a client object. In this manner, the objects can be developed and maintained by a party different from the party that developed the client application.
In order to standardize the data transfer process, several interfaces and protocols have been developed which allow objects in one program to interact with objects in another program which may be written in a different language and residing on a different platform. For example, one such specification was developed by an industry consortium called the Object Management Group (OMG) whose mission was to define a set of interfaces for inter-operable software. Its first specification, the Common Object Request Broker Architecture (CORBA) specification, is an industry consensus standard that hides all differences between programming languages, operating systems, and object location. The CORBA standard defines an object request broker (ORB) that handles the marshaling, transport and unmarshaling of information between applications and provides various standard object services, such as naming, life cycle, notification and persistence services. The ORB functions as a communication infrastructure, transparently relaying object requests across distributed heterogeneous computing environments. Inter-operability is accomplished through well-defined object interface specifications which allow client applications to connect to the ORB. CORBA also provides an implementation independent notation for defining interfaces called the OMG Interface Definition Language (IDL). Other distributed object protocols include Java RMI.
A distributed object system can also incorporate a data source, such as a database. The database is associated with a database server. A client object interacts with the database server in a conventional manner. The client object may also be viewed as a server from other client objects, as will be recognized by those skilled in the art. In order to use the database, the client object must first connect to the database and the connection then forwards database queries to the database and returns the result set. For example, in a distributed system which is compliant with the Java Database Connectivity API (JDBC), a client connects to the database by instantiating a connection object. The connection object then internally manages all aspects of the connection so that the details are transparent to the client. Effectively, the connection object acts as a pipeline to the underlying DBMS driver.
Although connection objects make interaction with a database straightforward, they do not manage resources well. For example, the client object may make repeated queries to a particular database and, consequently, it may be desirable to leave a database connection open even after a query has been completed. Since, most databases have a maximum number of simultaneous connections that can be handled, leaving connections open may cause the server to quickly exhaust the number of possible connections. Alternatively, if connections are closed after a query is complete, performance suffers since there is significant overhead involved in establishing a new connection to the same database if the same client should issue another query.
SUMMARY OF THE INVENTION
The foregoing problem is solved in one embodiment of the invention in which open connections are stored or “cached” in a connection manager at the client. Therefore, even when a query is complete and the connection between the client and server is released, the manager maintains the database connection open.
In accordance with one embodiment, connection information which can include the database name, user name and login password are stored in the connection manger for each open connection. When a new query arrives at the server, the connection manager compares the connection information in the query to the corresponding information stored for each open connection. If there is a match and the connection is not in use, the already open connection is used for the new query. If there is no match, a new connection is opened until a predetermined limit of the number of connections is reached. When the limit is reached, an open connection which is not in use is closed and a new connection is established.
Even though a query is completed, the connection manager does not close the connection until a new connection is needed and the connection number limit has been reached. Therefore, connections can be “shared” and the overhead involved in establishing new connections is significantly reduced.
In accordance with another embodiment, a “free” list of open connections which are not in use is maintained so that a quick comparison can be made with the incoming query information.
REFERENCES:
patent: 5596745 (1997-01-01), Lai et al.
patent: 5608900 (1997-03-01), Dockter et al.
patent: 5857201 (1999-01-01), Wright, Jr. et al.
patent: 5884297 (1999-03-01), Noven
patent: 5899990 (1999-05-01), Maritzen et al.
patent: 5974417 (1999-10-01), Bracho et al.
patent: 6092063 (2000-07-01), Cheng et al.
patent: 6112196 (2000-08-01), Zimowski et al.
patent: 6216151 (2001-04-01), Antoun
patent: 6226684 (2001-05-01), Sung et al.
Goldberg Robert N.
White Seth J.
Breene John
Kudirka & Jobse LLP
Le Debbie
Sun Microsystems Inc.
LandOfFree
System and method for reliable caching of database... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for reliable caching of database..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for reliable caching of database... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2927309