Database scattering system

Abstract

A computer system for providing load balancing and scalable access to a network database system by providing multiple database instances with each instance being substantially identical in data content, database structure, and primary key system. Requests from users are received by the system, examined to determine their nature as transactional or non-transactional and, in the case of non-transactional queries, scattered among the multiple database instances. Such scattering of queries permits multiple instances of the database to be serving responses to multiple users at substantially the same time. In the case of transactional queries, the system automatically propagates the transactional query to all instances of the database to maintain homogeneity.

Claims

1. A computer system for use in providing load balancing and scalable access to at least two first database replicated instances in a networked environment comprising a plurality of such first replicated database instances, available to a population of users, comprising:

a) at least one first computer processor structured and arranged to perform record retrieval essentially simultaneously from each of such at least two first database replicated instances;

b) at least one second computer processor structured and arranged to control processing of at least one update request onto each of such at least two first database replicated instances

c) at least one third computer processor structured and arranged to assign at least one unique identifier for each unique record in such at least two first database replicated instances;

d) at least one second database structured and arranged to store such at least one unique identifier;

e) at least one third database structured and arranged to store at least one copy of each such update request;

f) at least one fourth database structured and arranged to store location information for each at least two first database replicated instances used for record retrieval; and

g) wherein such at least one first computer processor is further structured and arranged to randomly select at least one such instance of such at least two first database replicated instances from such at least one fourth database.

2. The computer system according to claim 1 further comprising:

a) at least one fifth database structured and arranged to store location information for each at least two first database replicated instances to be updated; and

b) at least one fourth computer processor structured and arranged to restore at least one instance of at least two first database replicated instances not substantially identical to all other such instances of at least two first database replicated instances to substantial identicalness with all other such instances of such at least two first database replicated instances.

3. The computer system according to claim 2 wherein such at least one first computer processor is further structured and arranged to:

a) replicate itself automatically for each of at least two operating end-user computer processor systems; and

b) permit each copy of such at least one first computer processor for each of such at least two end-user computer processing systems direct communication with such at least one first database replicated instance.

4. The computer system according to claim 2 wherein such at least one first computer processor is further structured and arranged to:

a) receive at least one database request form at least one end-user computer processor system;

b) determine the nature of such at least one database request;

c) retrieve at least one requested record from at least one instance of such at least two first database replicated instances;

d) transmit such at least one retrieved requested record to the at least one end-user computer processor system;

e) transmit such at least one update request to such at least one second computer processor structured and arranged to control processing of at least one update request onto each of such at least two first database replicated instances; and

f) transmit update outcome information to the at least one end-user computer processor system.

5. The computer system according to claim 2 wherein such first computer processor is further structured and arranged to:

b) update such at least one fourth database when at least one such instance of such at least two first database replicated instances is non-responsive to retrieval requests by such at least one second computer processor; and

c) randomly select at least one such instance of such at least two first database replicated instances from such at least one fourth database when at least one such instance of such at least two first database replicated instances is non-responsive to retrieval requests by such at least one second computer processor.

6. The computer system according to claim 2 wherein such at least one second computer processor is further structured and arranged to:

a) receive such at least one update request from such at least one first computer processor;

b) insert at least one copy of such at least one update request onto such at least one third database;

c) retrieve such location information for at least one such instance of such at least two first database replicated instances from such at least one fifth database;

d) transmit at least one such update request to each such instance of such at least two first database replicated instances using such location information;

e) receive such update outcome information for each such update request transmitted to each such instance of such at least two first database replicated instances;

f) add such update outcome information to such at least one copy of such at least one update request on such at least one third database;

g) recognize failure of such at least one instance of such at least two first database replicated instances to accept at least one such update request;

h) transmit such update outcome information to such at least one first computer processor; and

i) initiate such at least one fourth computer processor.

7. The computer system according to claim 3 wherein such at least one fourth computer processor is further structured and arranged to:

a) test presence of such at least one instance of at least two first database replicated instances not substantially identical to all other such instances of at least two first database replicated instances;

b) test readiness of such at least one instance of at least two first database replicated instances not substantially identical to all other such instances of at least two first database replicated instances to accept update requests;

c) retrieve at least one unprocessed update request for such at least one instance of at least two first database replicated instances not substantially identical to all other such instances of such at least two first database replicated instances from such at least one third database;

d) transmit at least one unprocessed such update request to such at least one instance of at least two first database replicated instances not substantially identical to all other such instances of such at least two first database replicated instances;

e) receive such update outcome information for each unprocessed such update request transmitted to each such instance of such at least two first database replicated instances not substantially identical to all other such instances of such at least two first database replicated instances;

f) add such update outcome information to each such update request on such at least one third database;

g) manage transmission of all such unprocessed update requests until completion; and

h) transmit completion progress information to such at least one second computer processor.

8. The computer system according to claim 7 wherein such second computer processor is further structured and arranged to:

a) receive such completion progress information from such fourth computer processor;

b) suspend receiving such at least one update request from such at least one first computer processor when such completion progress information reaches a preset value;

c) resume receiving such at least one update request from such at least one first computer processor when such completion progress indicates all unprocessed such updates have been applied; and

d) transmit notification that such at least one such instance of such at least two first database replicated instances is substantially identical to all other such instances of such at least two first database replicated instances to at least one such first computer processor.

9. A computer software program, for use in providing load balancing and scalable access to at least two first database replicated instances in a networked environment comprising a plurality of such first replicated database instances, available to a population of users, comprising the step(s) of:

a) performing record retrieval essentially simultaneously from each of such at least two first database replicated instances;

b) controlling processing of at least one update request onto each of such at least two first database replicated instances;

c) assigning at least one unique identifier for each unique record in such at least two first database replicated instances;

d) storing such at least one unique identifier;

e) storing at least one copy of each such update request;

f) storing location information for each such at least two first database replicated instances used for record retrieval in at least one fourth database; and

g) randomly selecting at least one such instance of such at least two first database replicated instances used for record retrieval from such at least one fourth database.

10. The computer software program according to claim 9 further comprising the step(s) of:

a) storing location information for each such at least two first database replicated instances to be updated; and

b) restoring at least one instance of such at least two first database replicated instances not substantially identical to all other such instances of at least two first database replicated instances to substantial identicalness with all other such instances of such at least two first database replicated instances.

11. The computer software program according to claim 10 further comprising the steps of:

a) receiving at least one database request from at least one end-user computer processor system;

b) determining the nature of such at least one database request;

c) retrieving at least one requested record from at least one instance of such at least two first database replicated instances;

d) transmitting such at least one retrieved requested record to the at least one end-user computer processor system; and

e) transmitting update outcome information to the at least one end-user computer processor system.

12. The computer software program according to claim 10 further comprising the steps of:

b) updating such at least one fourth database when at least one such instance of such at least two first database replicated instances is non-responsive to retrieval requests; and

c) randomly selecting at least one such instance of such at least two first database replicated instances from such at least one fourth database when at least one such instance of such at least two first database replicated instances is non-responsive to retrieval requests.

13. The computer software program according to claim 10 further comprising the steps of:

a) inserting at least one copy of such at least one update request onto such at least one third database;

b) retrieving such location information for at least one such instance of such at least two first database replicated instances from such at least one fifth database;

c) transmitting at least one such update request to each such instance of such at least two first database replicated instances using such location information;

d) receiving such update outcome information for each such update request transmitted to each such instance of such at least two first database replicated instances;

e) adding such update outcome information to such at least one copy of such at least one update request on such at least one third database; and

f) recognizing failure of such at least one instance of such at least two first database replicated instances to accept at least one such update request.

14. The computer software program according to claim 1 further comprising the steps of:

a) testing for presence of such at least one instance of such at least two first database replicated instances not substantially identical to all other such instances of such at least two first database replicated instances;

b) testing for readiness of such at least one instance of such at least two first database replicated instances not substantially identical to all other such instances of such at least two first database replicated instances to accept update requests;

c) retrieving at least one unprocessed update request for such at least one instance of such at least two first database replicated instances not substantially identical to all other such instances of such at least two first database replicated instances from such at least one third database;

d) transmitting at least one unprocessed such update request to such at least one instance of such at least two first database replicated instances not substantially identical to all other such instances of such at least two first database replicated instances;

e) receiving such update outcome information for each unprocessed such update request transmitted to each such instance of such at least two first database replicated instances not substantially identical to all other such instances of such at least two first database replicated instances;

f) adding such update outcome information to each such update request on such at least one third database; and

g) managing transmission of all such unprocessed update requests until completion.

15. The computer software program according to claim 14 further comprising the steps of:

a) suspending receiving such at least one update request when such completion progress information reaches at least one preset value; and

b) resuming receiving such at least one update request when such completion progress indicates all unprocessed such updates have been processed.

16. A software method, for network database environments, permitting load balancing, scalability and substantially simultaneous use by client users, comprising the steps of:

a) providing multiple database instances wherein each such instance is substantially identical in data content, database structure, and primary key system;

b) maintaining substantially real time records of status for each such multiple database instance;

c) receiving a database query from at least one end-user application and determining such query to be a transactional query or non-transactional query;

d) directing such database query to at least one selected instance of such multiple database instances upon a determination of such query being a non-transactional query;

e) returning such non-transactional query results to the at least one end-user application;

f) directing such database query to all instances of such multiple database instances upon a determination of such query being a transactional query;

g) controlling such transactional queries to maintain substantial identicalness among such multiple database instances;

h) propagating such transactional queries to such multiple database instances;

i) returning such query results to the user;

j) recognizing a failure in at least one instance of such multiple database instances, and adjusting to store such transactional query for later propagation;

k) restoring such failed at least one instance of such multiple database instances to substantial identicalness with other such multiple database instances.

17. The method according to claim 16 wherein each such non-transactional query is executed upon a randomly selected instance of such multiple database instances.

18. The method according to claim 16 wherein the processing of such non-transactional query commands as directed by a plurality of users is substantially simultaneous.

19. A business system, for network database environments, permitting load balancing, scalability and substantially simultaneous use by client users, comprising the steps of:

a) providing multiple database instances wherein each such instance is substantially identical in data content, database structure, and primary key system;

b) providing a middleware software management to directly manage access to such multiple instances of the database, wherein such middleware software management performs the steps of;

i) establishing a single source for maintaining substantially real time records of status for such multiple database instances;

ii) providing a plurality of interface instances to receive a database query from at least one user,

iii) determining such query to be a transactional query or non-transactional query;

iv) directing such non-transactional query to an available instance of such multiple database instances determined to be available by such real time records of status;

v) directing such transactional query to all available instances of such multiple database instances determined to be available by such real time records of status;

vi) returning such query results to the user.

20. A business method according to claim 19 wherein the processes of such middleware software management and existence of such multiple instances of the database are transparent to the user, the user perceiving only a single, ultra responsive database.

Description

BACKGROUND

The present invention relates to a method and system for increasing scalability and reliability of database applications, and, more particularly, the use of a scattering method and system to reduce system load and improve response performance. In the modem business environment, reliance upon computers and computer systems is found in almost every setting. Information (and its exchange, retrieval, processing, updating, and, of course, safekeeping) is perhaps the most common and most important aspect of computer interaction. Most commonly, the data records are placed within a server database that has been configured to store pertinent data. This server database is typically accessed by remote computer systems ("clients") as and when the users of the client systems have needs to retrieve, manipulate or store information.

Despite advances in computer memory chip technology, the vast majority of database systems in operation today make use of physical storage systems, such as hard drives, to store the information arranged within the database structure. There are several factors which must be considered in the design and architecture of a database system; however, in almost all cases the defining issue of concern is speed. Although parallel processing and operation is commonplace with operations performed within the environment of a computer chip, the physical operations performed by hard drives and other physical storage devices mandate that nearly each and every database operation involves an activity that must be individually performed for a specific client user before the next desired operation may be performed for either the same or another next client user.

Database maintenance is a necessary evil; a properly tuned and maintained database is the most efficient in its ability to serve requests, perform updates, and record new data. During the operation of a database and subsequent periods of maintenance, it is often discovered that initial parameters are not currently desired. And greater efficiency may be achieved through fundamental restructuring of the database elements. Such processes are time-consuming; and, during such processes, the database is not available to client users for its intended purpose of serving data. Thus, mirror backups ideally must be maintained such that the level of service is not disrupted. Creating and maintaining backup copies of a database is often far from simplistic; by its nature a database is not static. Any backup copy that is developed is only a snapshot in time unless it too enjoys the same updates and modifications performed upon the primary master database. By implication, therefore, the backup server database system or systems must be similar in performance characteristics so as to keep up with the primary server database write and update operations.

In the majority of settings, client users access a server database simply for the purpose of reading data. It is not uncommon for the "Read" requests to outnumber the write requests by a factor of at least 5 to 1. For a Read request (defined as a non-transactional operation reading stored data), very little is required of the database other than to find and deliver the appropriate record being queried. Yet the physical operation of locating the record and returning its contents impose a cueing upon the client users such that their requests are processed on a first-come first-served basis.

Given that there are different operating systems (such as Microsoft Widows, OS 2, and quite a variety of flavors of Linux); there are also a variety of different off-the-shelf database applications as well as custom-developed database systems. Attempts to develop software systems to improve response times to Read requests and provide some options of scalability are, by and large, platform-specific and database-specific. This is an unattractive condition in view of the many different types of database users.

To maximize performance, and thus increase response times, it is typical for server databases to be quite robust in terms of their physical storage capabilities, processor speeds, volume of random access memory, etc. The larger and more powerful the database system, the larger numbers of client users can be served in the same amount of time. However, such size and power may be investments not fully appreciated for some time, if ever; and limitations always remain with respect to how many client users can be served adequately. Down-time in waiting for a response from the database is very frequently related to the overall level of productivity achieved by client users.

Thus, a great need exists for a system capable of improving resource management and permitting substantially simultaneous data access requests without undue expense in hardware.

OBJECTS OF THE INVENTION

It is a primary object and feature of this invention to fill the above-mentioned needs. It is a further object and feature of the present invention to provide a method and system for allocating resource needs and data access requests across a plurality of server databases, each containing a mirrored copy of the database at issue.

Still another object and feature of the present invention is to permit scattering of mirrored copies of the database by means of transparent middleware that is independent from and non-reliant upon the type of database software or operating system actually selected for use by the database system architect. Another object and feature of the present invention is to permit substantially simultaneous access to physically different records within a given database by directing each Read request to physically-separate duplicate copies of the database.

Yet another object and feature of the present invention is to permit use of the widely-available and well-understood networking methodologies of TCP/IP for interlinking and coordination of the scattered server database components. Another object and feature of the present invention is to permit automated database backup without requiring a live database to be taken off line. A further object and feature of the present invention is to permit addition or deletion of a mirroring database, either as a primary or backup system, with such addition or deletion being performed without disruption of database access to the client users.

Still another object and feature of the present invention is to provide a means for identifying and tracking the state of each mirrored copy of the database. Another object and feature of the present invention is to permit automated and systematic load balancing of resource requests throughout the scattered database system. Another object and feature of the present invention is to permit scalability of database capabilities when and as client user needs require expansion of the database, thus alleviating need for investment in hardware systems and services before such time as they are required.

SUMMARY OF THE INVENTION

In accordance with a preferred embodiment of the present invention provides a computer system for use in providing load balancing and scalable access to at least two first database replicated instances in a networked environment comprising a plurality of such first replicated database instances, available to a population of users, comprising: at least one first computer processor structured and arranged to perform record retrieval essentially simultaneously from each of such at least two first database replicated instances. Moreover, it provides such a computer system further comprising: at least one second computer processor structured and arranged to control processing of at least one update request onto each of such at least two first database replicated instances. Additionally, it provides such a computer system further comprising: at least one third computer processor structured and arranged to assign at least one unique identifier for each unique record in such at least two first database replicated instances; at least one second database structured and arranged to store such at least one unique identifier; at least one third database structured and arranged to store at least one copy of each such update request; at least one fourth database structured and arranged to store location information for each at least two first database replicated instances used for record retrieval; at least one fifth database structured and arranged to store location information for each at least two first database replicated instances to be updated; and at least one fourth computer processor structured and arranged to restore at least one instance of at least two first database replicated instances not substantially identical to all other such instances of at least two first database replicated instances to substantial identicalness with all other such instances of such at least two first database replicated instances.

Also, it provides such a computer system wherein such at least one first computer processor is further structured and arranged to: receive at least one database request from at least one end-user computer processor system; determine the nature of such at least one database request; retrieve at least one requested record from at least one instance of such at least two first database replicated instances; transmit such at least one retrieved requested record to the at least one end-user computer processor system; transmit such at least one update request to such at least one second computer processor structured and arranged to control processing of at least one update request onto each of such at least two first database replicated instances; and transmit update outcome information to the at least one end-user computer processor system. In addition, it provides such a computer system wherein such first computer processor is further structured and arranged to: randomly select at least one such instance of such at least two first database replicated instances from such at least one fourth database; update such at least one fourth database when at least one such instance of such at least two first database replicated instances is non-responsive to retrieval requests by such at least one second computer process; and randomly select at least one such instance of such at least two first database replicated instances from such at least one fourth database when at least one such instance of such at least two first database replicated instances is non-responsive to retrieval requests by such at least one second computer process. And, it provides such a computer system wherein such at least one second computer processor is further structured and arranged to: receive such at least one update request from such at least one first computer processor; insert at least one copy of such at least one update request onto such at least one third database; retrieve such location information for at least one such instance of such at least two first database replicated instances from such at least one fifth database; transmit at least one such update request to each such instance of such at least two first database replicated instances using such location information; receive such update outcome information for each such update request transmitted to each such instance of such at least two first database replicated instances; add such update outcome information to such at least one copy of such at least one update request on such at least one third database; recognize failure of such at least one instance of such at least two first database replicated instances to accept at least one such update request; transmit such update outcome information to such at least one first computer processor; and initiate such at least one fourth computer processor.

Further, it provides such a computer system wherein at least one fourth computer processor is further structured and arranged to: test presence of such at least one instance of at least two first database replicated instances not substantially identical to all other such instances of at least two first database replicated instances; test readiness of such at least one instance of at least two first database replicated instances not substantially identical to all other such instances of at least two first database replicated instances to accept update requests; retrieve at least one unprocessed update request for such at least one instance of at least two first database replicated instances not substantially identical to all other such instances of such at least two first database replicated instances from such at least one third database; transmit at least one unprocessed such update request to such at least one instance of at least two first database replicated instances not substantially identical to all other such instances of such at least two first database replicated instances; receive such update outcome information for each unprocessed such update request transmitted to each such instance of such at least two first database replicated instances not substantially identical to all other such instances of such at least two first database replicated instances; add such update outcome information to each such update request on such at least one third database; manage transmission of all such unprocessed update requests until completion; and transmit completion progress information to such at least one second computer processor. Even further, it provides such a computer system wherein such second computer processor is further structured and arranged to: receive such completion progress information from such fourth computer processor; suspend receiving such at least one update request from such at least one first computer processor when such completion progress information reaches a preset value; resume receiving such at least one update request from such at least one first computer processor when such completion progress indicates all unprocessed such updates have been applied; and transmit notification that such at least one such instance of such at least two first database replicated instances is substantially identical to all other such instances of such at least two first database replicated instances to at least one such first computer processor.

In accordance with another preferred embodiment hereof, this invention provides a computer software program, for use in providing load balancing and scalable access to at least two first database replicated instances in a networked environment comprising a plurality of such first replicated database instances, available to a population of users, comprising the step(s) of: performing record retrieval essentially simultaneously from each of such at least two first database replicated instances. Moreover, it provides such a computer software program further comprising the step(s) of: controlling processing of at least one update request onto each of such at least two first database replicated instances. Additionally, it provides such a computer software program further comprising the steps of: assigning at least one unique identifier for each unique record in such at least two first database replicated instances; storing such at least one unique identifier; storing at least one copy of each such update request; storing location information for each such at least two first database replicated instances used for record retrieval; storing location information for each such at least two first database replicated instances to be updated; and restoring at least one instance of such at least two first database replicated instances not substantially identical to all other such instances of at least two first database replicated instances to substantial identicalness with all other such instances of such at least two first database replicated instances.

Also, it provides such a computer software program further comprising the steps of: receiving at least one database request from at least one end-user computer processor system; determining the nature of such at least one database request; retrieving at least one requested record from at least one instance of such at least two first database replicated instances; transmitting such at least one retrieved requested record to the at least one end-user computer processor system; and transmitting update outcome information to the at least one end-user computer processor system. In addition, it provides such a computer software program further comprising the steps of: randomly selecting at least one such instance of such at least two first database replicated instances from such at least one fourth database; updating such at least one fourth database when at least one such instance of such at least two first database replicated instances is non-responsive to retrieval requests; and randomly selecting at least one such instance of such at least two first database replicated instances from such at least one fourth database when at least one such instance of such at least two first database replicated instances is non-responsive to retrieval requests. And, it provides such a computer software program further comprising the steps of: inserting at least one copy of such at least one update request onto such at least one third database; retrieving such location information for at least one such instance of such at least two first database replicated instances from such at least one fifth database; transmitting at least one such update request to each such instance of such at least two first database replicated instances using such location information; receiving such update outcome information for each such update request transmitted to each such instance of such at least two first database replicated instances; adding such update outcome information to such at least one copy of such at least one update request on such at least one third database; and recognizing failure of such at least one instance of such at least two first database replicated instances to accept at least one such update request.

Further, it provides such a computer software program further comprising the steps of: testing for presence of such at least one instance of such at least two first database replicated instances not substantially identical to all other such instances of such at least two first database replicated instances; testing for readiness of such at least one instance of such at least two first database replicated instances not substantially identical to all other such instances of such at least two first database replicated instances to accept update requests; retrieving at least one unprocessed update request for such at least one instance of such at least two first database replicated instances not substantially identical to all other such instances of such at least two first database replicated instances from such at least one third database; transmitting at least one unprocessed such update request to such at least one instance of such at least two first database replicated instances not substantially identical to all other such instances of such at least two first database replicated instances; receiving such update outcome information for each unprocessed such update request transmitted to each such instance of such at least two first database replicated instances not substantially identical to all other such instances of such at least two first database replicated instances; adding such update outcome information to each such update request on such at least one third database; and managing transmission of all such unprocessed update requests until completion. Even further, it provides such a computer software program further comprising the steps of: suspending receiving such at least one update request when such completion progress information reaches at least one preset value; and resuming receiving such at least one update request when such completion progress indicates all unprocessed such updates have been processed.

In accordance with another preferred embodiment hereof, this invention provides a software method, for network database environments, permitting load balancing, scalability and substantially simultaneous use by client users, comprising the steps of: providing multiple database instances wherein each such instance is substantially identical in data content, database structure, and primary key system; maintaining substantially real time records of status for each such multiple database instance; receiving a database query from at least one end-user application and determining such query to be a transactional query or non-transactional query; directing such database query to at least one selected instance of such multiple database instances upon a determination of such query being a non-transactional query; returning such non-transactional query results to the at least one end-user application; directing such database query to all instances of such multiple database instances upon a determination of such query being a transactional query; controlling such transactional queries to maintain substantial identicalness among such multiple database instances; propagating such transactional queries to such multiple database instances; returning such query results to the user; recognizing a failure in at least one instance of such multiple database instances, and adjusting to store such transactional query for later propagation; restoring such failed at least one instance of such multiple database instances to substantial identicalness with other such multiple database instances. Moreover, it provides such a method wherein each such non-transactional query is executed upon a randomly selected instance of such multiple database instances. Additionally, it provides such a method wherein the processing of such non-transactional query commands as directed by a plurality of users is substantially simultaneous.

In accordance with another preferred embodiment hereof, this invention provides a business system, for network database environments, permitting load balancing, scalability and substantially simultaneous use by client users, comprising the steps of: providing multiple database instances wherein each such instance is substantially identical in data content, database structure, and primary key system; providing a middleware software management to directly manage access to such multiple instances of the database, wherein such middleware software management performs the steps of establishing a single source for maintaining substantially real time records of status for such multiple database instances; providing a plurality of interface instances to receive a database query from at least one user, determining such query to be a transactional query or non-transactional query; directing such non-transactional query to an available instance of such multiple database instances determined to be available by such real time records of status; directing such transactional query to all available instances of such multiple database instances determined to be available by such real time records of status; returning such query results to the user.

In accordance with another preferred embodiment hereof, this invention provides a business method wherein the processes of such middleware software management and existence of such multiple instances of the database are transparent to the user, the user perceiving only a single, ultra responsive database.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified schematic illustration of the components comprising a preferred embodiment of the present invention.

FIG. 2 is a simplified schematic illustration of the present invention processing a non-transactional query operation according to a preferred embodiment.

FIG. 3 is a simplified schematic illustration of the present invention processing a transactional query operation according to a preferred embodiment.

FIG. 4 is a simplified schematic illustration of the present invention processing recovery of a failed database according to a preferred embodiment.

FIG. 5 is a simplified schematic illustration of the present invention depicting the use of multiple scatter sets within a database cluster according to a preferred embodiment.

FIG. 6 is a simplified schematic illustration of the components comprising an alternate preferred embodiment of the present invention.

FIG. 7 is a simplified schematic illustration of the present invention responding to a user according to an alternate preferred embodiment.

FIG. 8 is a simplified schematic illustration of the present invention processing a non-transactional query operation according to an alternate preferred embodiment.

FIG. 9 is a simplified schematic illustration of the present invention processing a transactional query operation according to an alternate preferred embodiment.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT OF THE INVENTION

Preferred Embodiment

With the intention of enabling the present invention to be more readily understood by those skilled in the art, while at the same time disclosing the advantages that are afforded by the present invention, the following description is subdivided to provide an overview of the primary components giving rise to a preferred embodiment of the present invention (the Transaction Server, ScatterOp, Scatter Log, Global ID Broker, and Administration System). Within each subsection of description reference is made by title to other system components when and as necessary to assist in understanding system inter-relationships.

Following the description of each sub-component and an identification of the pathways of communication between components, a description of the interaction of the components in functional application as taught by the present invention is provided.

A fundamental principle as taught by the present invention rests upon the premise that multiple database users can and will have their needs more efficiently met if each or nearly each has access to the database without having to wait in turn for database access. More specifically, just as multiple copies of the same text book permit students to review the same subject, though perhaps different portions thereof, each with their own book, so too multiple copies of a database will enhance database interaction performance. However, to insure that each instance of the database is a substantially identical peer to every other instance, transactional operations must be effectuated upon all copies of the database. As application of the present invention is primarily intended for database situations and settings where non-transactional requests outnumber transactional requests by a factor of at least 5 or 6 to 1, the benefits of simultaneous access are significant.

It is the scattering of operations while achieving homogeneous status between the multiple copies of the database that is a primary feature taught by the present invention. More specifically, it provides, preferably, that non-transactional operations are "scattered" among a plurality of substantially identical peer copies of the database.

In the accompanying drawings, well-known structures and devices are shown in block diagram form in order to provide an understanding of the interrelationship between components and the flow of information and control throughout the depicted preferred embodiment of the present invention. It will be apparent to one skilled in the art that the invention may be practiced with a variety of different specific components, without detraction or departure from the scope of the present invention, provided to serve the generalized block diagram description. Further, for the purposes of the following discussion, it is to be understood that a transactional operation upon the database is one in which data is added, modified or deleted from the database. Specific statements made with respect to any of these operations are intended to clarify the nature of the operation being performed, but should not be taken as a limitation of the operation should an alternative transactional operation be desired in a substantially similar situation or setting.

It is also to be understood that the objects comprising the preferred embodiment may be coded in a language of preference to the developer without departure from the spirit or teachings of present invention. More specifically, encoding in a particular specific language, such as C, Java, C++, C-Prime, or other language, is not to be seen as restrictive to the scope of the present invention.

Transaction Server

A preferred embodiment of the present invention provides for allocation of resource needs and data access across a plurality of databases copies (database instances) each residing on its own server. To achieve this, there is preferably a process for managing updates and the information relating to the status of the scattered database system itself, i.e., the status of each database instance.

This centralized process, as described herein, comprises the Transaction Server, an extremely lightweight application preferably existing on its own ultra-fast hardware system. Preferably, the Transaction Server is connected solely by TCP/IP to the rest of the system embodying the present invention. Preferably, as connection to the system is by TCP/IP only, it is a connection channel established with sufficient bandwidth to accommodate the predicted level of traffic. Under appropriate circumstances, it may be desired to maintain multiple high-bandwidth connection paths with a plurality of unrelated providers such that a failure in one provider's network will not significantly impede operation of the present invention. Under appropriate circumstances, the Transaction Server may be placed within the same local network environment of the Read/Write Databases and application servers, thereby enjoying increased TCP/IP connectivity and bandwidth resources without additional costs to access providers.

Further, the Transaction Server is preferably a fast, configurable socket server operating in a multithreaded capacity to concurrently receive, process and answer all incoming requests. All data transfer to and from the Transaction Server is preferably performed in XML grammar.

Preferably, the Transaction Server performs all database command writing, maintains current information on the status of each Local Read/Write Database to ensure data integrity and each remote Write-Only Database and manages recovery of previously failed Local Read/Write Databases and Write-Only databases. Also, preferably, the Transaction Server is the sole entity responsible for maintaining a log of all pending and completed database commands (herein embodying at least one second computer processor structured and arranged to control processing of at least one update request onto each of such at least two first database replicated instances; and herein embodying controlling processing of at least one update request onto each of such at least two first database replicated instances).

Preferably, Local Read/Write Database update operations are not handled in the manner used for processing of read operations. Specifically, functionality of a database system incorporating the preferred embodiment of the present invention is preferably achieved by insuring uniform symmetry of data throughout all Local Read/Write Databases. To achieve and maintain such uniform symmetry, i.e., uniformity, the Transaction Server preferably must direct each and every write operation requested by a ScatterOp to all Local Read/Write Databases, before a subsequent write operation may be performed.

It is to be noted that for each instance of a Local Read/Write Database present in the system, there is preferably one entry in a list of connection string records used solely by the Transaction Server for accessing each Local Read/Write Database (herein embodying at least one fifth database structured and arranged to store location information for each at least two first database replicated instances to be updated). Similar to how databases themselves keep transaction logs, the Transaction Server preferably keeps a Scatter Log, logging every statement to be written to each Local Read/Write database. Preferably, before the Transaction Server attempts to write the statement to the Local Read/Write Databases in the cluster, it writes the statement to the Scatter Log. After it has attempted to write the statement to each database in the cluster, the Transaction Server preferably writes the status of each attempt for each individual Local Read/Write Database to the Scatter Log, logging commits and any failures of any individual Local Read/Write Database in the cluster or of any Write-Only database. This log is preferably used to insure data integrity and synchronization of all database servers in the cluster in the event of system failure of the Transaction Server. The Scatter Log itself is preferably a database which can be located on the Transaction Server or on another nearby server.

To successfully process updates, the Transaction Server preferably must support, at a minimum, the fundamental database commands recognizable to those skilled in the art, e.g., ExecuteGet, ExecuteGetScalar, ExecuteNonQuery, and ExecuteInsert. Further, the Transaction Server will preferably support, at a minimum, the minimum database interaction commands, e.g., Begin Transaction, Commit Transaction, and Rollback Transaction. These interaction commands serve to direct the database to begin the requested operation, effectively commit the changes of the requested transaction, and rollback and not commit the changes of the requested transaction. Proper synchronization between the Local Read/Write Databases when performing transactional operations is achieved through the use of the Scatter Log as described above.

If the Transaction Server has witnessed any failures in writing update statements to any individual Local Read/Write Database in the cluster, preferably the Transaction Server marks each failed Local Read/Write Database offline in the Scatter Log and starts a "ping" process for each failed Local Read/Write Database to determine when it is back online. As each failed Local Read/Write Database is determined to be back online the "ping" process preferably starts the recovery process for each failed Local Read/Write Database. Preferably the recovery process brings each failed Local Read/Write Database up-to-date, giving it all the update operations it missed from the Scatter Log while it was offline beginning with the transaction on which the failure occurred (herein embodying at least one fourth computer processor structured and arranged to restore at least one instance of at least two first database replicated instances not substantially identical to all other such instances of at least two first database replicated instances to substantial identicalness with all other such instances of such at least two first database replicated instances). During the recovery process, each failed Local Read/Write Database preferably remains marked as offline to the Transaction Server. Preferably, any additional updates that occur during the recovery process continue to be added to the Scatter Log as they normally would be, but marked as not written to each failed Local Read/Write database.

As the recovery process nears completion as set by a preset threshold of remaining updates, the recovery process preferably signals the Transaction Server to pause any new begin transaction requests and preferably waits until all currently pending transactions are completed (whether a commit or rollback) for all other Local Read/Write Databases, before completing the last remaining updates to the failed Local Read/Write Database and reinstating it into service. The preset threshold of remaining updates is preferably configurable by the database administrator.

The purpose for this pause is to give the recovery process a chance to "beat" the incoming volume of write requests by allowing it to finish recovering without having to worry about additional incoming commands. During periods of high write volume, if the recovery process waited until every missed statement from the Scattering Log was written to the failed Local Read/Write database, the failed Local Read/Write Database would take longer to get caught up, as new entries are added as fast as they are written to the lagging failed database. Higher threshold values cause the failed Local Read/Write Database to come back online quicker, but cause longer pause periods. Lower threshold values cause the failed Local Read/Write Database to come back online slower, but create shorter pause periods. Preferably, the total pause time is typically between 1 and 10 seconds, depending on the threshold value set.

Preferably, a slight pause is always necessary to bring the failed Local Read/Write Database back online in the same transactional context as every other database in the cluster. Preferably the Transaction Server must guarantee synchronization of Begin Transaction commands across every Local Read/Write Database in the cluster. Preferably, each Begin Transaction command issued by a ScatterOp must be completed on all Local Read/Write Databases before the next Begin Transaction command from that ScatterOp is issued by the Transaction Server to ensure that commands within the opened Begin Transaction command arrive in the same transactional context in each Local Read/Write database. Preferably, the commands within a transaction after the Begin Transaction command are managed by each Local Read/Write Database for performance reasons. Preferably, the Transaction Server may start another Begin Transaction command issued by another instance of a ScatterOp. Therefore, it is preferable that the failed Local Read/Write Database be brought back online at a point where it can synchronize Begin Transaction commands with the next incoming transaction. For this reason, it cannot be brought back online at any time. Preferably, when the failed Local Read/Write Database is completely up to date, the recovery process signals the Transaction Server to pause incoming requests so that no new Begin Transaction commands can begin until the failed Local Read/Write Database has been marked as available and can again perform Begin Transaction commands in real-time along with the other online Local Read/Write Databases. When the failed Local Read/Write Database is marked as available it also becomes available to the ScatterOp for any non-transactional operations.

Under appropriate circumstances, multiple Transaction Servers may be implemented in a cluster to improve performance. Preferably, in this arrangement the ScatterOps may send update requests to more than one Transaction Server. Preferably, there will be multiple Transaction Servers simultaneously accepting requests from multiple ScatterOps. Preferably, when a transaction has been started on one Transaction Server, it will remain the responsibility of that Transaction Server until completion, whether commitment or rollback. Preferably, once a transaction is started on a Transaction Server every subsequent statement pertaining to that transaction must be routed to the same Transaction Server, until the transaction has either committed or aborted. Preferably, each ScatterOp chooses a Transaction Server on which to execute a particular transaction in a round robin fashion. Preferably, the Scattering Log accepts transaction updates from each Transaction Server in the cluster recording the transaction requests and results in a sequential manner to ensure recovery of failed instances of the database. Preferably, a Distributed Semaphore is used to ensure that all begin transaction, commit transaction and rollback transaction statements are serialized across every Transaction Server in the cluster. This is necessary to ensure that when the Scattering Log is "played back" after a failure. The exact same begin, commit and rollback order is maintained across every instance of the singular database.

Restructuring of any data maintained by the Transaction Server, not achieved automatically through normal operation of the automated components of the system, is preferably to be performed by means of an administration application program. Such restructuring of data is understood to include, but is not necessarily limited to, the administrative tasks of updating the Transaction Server awareness of available Read/Write Databases and Write-Only Databases.

It should be noted that by intentional design of TCP/IP, communications directed to the Write-Only Databases may not always arrive in the precise sequence in which they were sent. Therefore, preferably, the Transaction Server makes use of the Scatter Log (described in further detail below) to provide a unique sequence identifier to each SQL statement transmitted to the Write-Only Databases, thus insuring that the write directives occur in the proper sequence.

Due to the nature of communication over the Internet, it is recognized that connection between the Transaction Server and the Local Read/Write Databases and Write-Only Databases is not infallible. It is therefore preferred under the present invention to permit the system administrator to define a timeout variable. If a connection to a component cannot be obtained within the defined timeout period, the connection attempt will be deemed a failure and the system will advance in accordance with its design parameters. Specifically, in most cases, such breach of a timeout period will result in the Transaction Server marking the Local Read/Write Database or Write-Only Database as effectively unavailable.

According to a preferred embodiment of the present invention, data integrity between all Local Read/Write Databases in the cluster will be maintained even in the case of an unexpected failure of the Transaction Server. Upon Transaction Server failure, preferably all transactions the Transaction Server was in progress of processing are left in the same state across each database in the cluster. Preferably, the Transaction Server is responsible for synchronizing the Begin Transaction, Commit and Rollback commands for each database in the cluster, which are the only operations throughout a transaction's lifetime which needs to be synchronized across databases to insure data integrity. Preferably, each individual database itself will manage synchronization of all related SQL commands on its own from that point. Preferably, the Commit and Rollback commands are not necessary to synchronize for a live running system, but it is necessary to know the commit order when replaying transactions for failed Local Read/Write Databases in the recovery process.

When the Transaction Server is unavailable, preferably both read access and write access are suspended to the entire system of Local Read/Write Databases until the Transaction Server comes back online. Because the Transaction Server is the only point where database write operations can be performed, its offline state alone preferably prevents any additional write operations from taking place. As noted above, read operations are performed by the ScatterOp object, outside the Transaction Server, but the ScatterOp will preferably discover the Transaction Server outage at the next write attempt. Once a ScatterOp has determined that the Transaction Server is down, preferably it notes that locally and will not allow any additional read or write access. All future read or write attempts requested of the ScatterOp preferably will first attempt to communicate to the Transaction Server to determine if it has been brought back online. Preferably, the ScatterOp will notify the requesting application of a read or write failure if the Transaction Server is offline. If the Transaction Server is online the ScatterOp will preferably proceed normally with its requests.

According to a preferred embodiment of the present invention, when the Transaction Server comes back online after a failure, preferably it can determine where it left off by comparing the Scattering Log's status for the pending transactions to the status of the transaction log for each individual Local Read/Write Database in the cluster to determine in which Local Read/Write Databases the transaction was committed and in which Local Read/Write Databases the transaction was not committed at the time of Transaction Server failure. Preferably, with this information, it can determine which databases require the transaction to be re-sent in order to bring the application's transaction to a successful completion on all the Local Read/Write Databases.

Summarizing, there is only one instance of the Transaction Server and the relationship of communications involving the Transaction Server is as follows: