Method and apparatus for transaction processing in a distributed database system

Abstract

A subscriber management system includes at least one Data Directory Server (DDS) located between one or more transaction generators and one or more data servers. The DDS efficiently routes transactions and provides data location functions. The DDS provides high data availability, high on-line transaction rates, batch capabilities, scalability and maintainability. In particular, based upon internal rules within the DDS and the particular transaction type, the DDS routes transactions to the appropriate server(s). Transactions are classified according to where they may be executed. Specifically, transactions may be classified as SPECIFIC, ANY or ALL. A SPECIFIC transaction must be processed at one or more specific servers irrespective of the accompanying arguments. An ANY transaction may be processed at any of the enterprise servers and selection is made randomly. Finally, an ALL transaction requires sequencing through each of the data servers within the enterprise and repetitively performing the transaction.

Claims

We claim:

1. A distributed database system comprising:

transaction generator means for generating database transactions;

a plurality of data servers; and

data directory server means in communication with said transaction generator means and each of said data servers, said data directory server means receiving database transactions from said transaction generator means and selecting at least one data server for processing each said database transaction.

2. The system of claim 1 wherein said data directory server means determines the type of database transaction received and determines whether the received database transaction is processed by a specific data server, by any data server or by all data servers.

3. The system of claim 1 further comprising at least one cross-reference server, said cross-reference servers providing data location information to said data directory servers.

4. The system of claim 3 wherein said cross-reference servers further provide a rules base to said data directory servers.

5. The system of claim 1 further comprising a control application, said control application initiating and modifying a rules base implemented by said data directory servers.

6. The system of claim 1 wherein said database transactions are routed by said data directory server based upon a transaction type.

7. The system of claim 6 wherein said transaction types consist of Specific, Any and All.

8. The system of claim 6 wherein said data server for processing each said database transaction is further selected based upon transaction arguments.

9. The system of claim 1 wherein at least one of said transaction generators comprises an automatic response unit.

10. The system of claim 9 wherein said transaction unit comprising an automatic response unit further includes an automatic number indicator for determining caller telephone numbers.

11. The system of claim 1 wherein said transaction generators comprise personal computers.

12. The system of claim 1 wherein said data servers and said data directory servers comprise open servers.

13. A subscriber management system for processing subscriber account records comprising:

a plurality of client terminals for operation by a customer service representative for initiating database transactions:

a plurality of servers for storing said subscriber account records and allowing read and write access to said subscriber account records: and

at least one data directory server for determining which of said servers is to be accessed for processing said database transactions, said data directory server being in communication with each of said client terminals and each of said servers;

further comprising at least one cross reference server, said cross reference servers indicating each of the accessible servers in said subscriber management system.

14. The subscriber management system of claim 13 wherein said cross reference servers farther indicate rule boundary information binding particular database transactions to particular servers.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to a method and system for processing transactions in a distributed database system.

2. Background of the Invention

With the increasing demand for the rapid processing of transactions, as well as the ever-increasing size of databases that these transactions must be processed against, many have turned to distributed database systems to accomplish their goals. For purposes of this disclosure, the term "distributed database" shall refer to a database system in which data is located in more than one physical location and/or in more than one database. In some cases, data may be distributed such that certain data is located in only one database while other data is located on more than one database. Usually, more than one client or user needs to access the data at the same time. Typically, many users require simultaneous or near simultaneous access. This presents a problem in that only a limited number of access requests can be processed at a time.

Access requests to databases generally are one of two types. The first is termed a "query" and is associated with a request to read data from the database(s). The second is termed an "update" and is associated with a request to write data to the database(s). For purposes of this discussion, both types of requests (and combinations thereof) shall be referred to generally as a "transaction." It is to be understood, however, that a transaction may involve one or more of either or both types of requests.

Various problems exist with distributed database systems. For example, in some cases multiple clients or users may request access to particular data at the same time. Typically, each data server may process one transaction (or a series of transactions) at a time. Thus, if multiple requests are made to one server at the same time, not all of the transactions can be processed at the same time. When this occurs the latter requests are generally queued or have to be resubmitted at a later time. This causes undesirable delays in the processing of these transactions. Other factors also contribute to delays in processing such transactions. As a result, in some cases, one or more data servers may be idle while another is backlogged with multiple requests. This is obviously an inefficient use of resources.

In an attempt to address these types of problems, some systems have used different schemes to attempt to balance the distribution of requests among the multiple servers. According to one arrangement, particular clients or users are permanently associated with particular servers. The theory behind this design is that by randomly limiting the number of clients accessing a particular data server, some minimization of the bottleneck effect may occur. According to another approach, multiple copies of particular data are stored in more than one database.

These schemes, however, generally suffer from at least three drawbacks. Firstly, many of the systems electing the first scheme are architected so that particular clients are "hard-wired" to particular servers. In such a case, clients in the system will not generally have access to the full complement of servers available in the system which are capable of processing the particular transaction. As a result, uneven load distribution may still occur since a server which is free to service a request may not be called upon to do so since the requesting client may not have access to the free server.

A second major drawback to both of the prior art data distribution schemes described above is the significant time and cost of processing information which is necessary to determine the best way to allocate data requests. In some cases, particularly when the number of transactions to be processed is low and the complexity of the allocation scheme is high, the system performs more efficiently without a real-time decisional process.

Thirdly, in the case of distributed database systems containing redundant data (e.g. the second scheme), the availability of secondary storage (i.e. disk storage) is significantly decreased by virtue of the redundancy of the data. Often data redundancy is not a possibility because of severe limitations in storage capacity within an enterprise.

One particular industry having a great need for storage and manipulation of large amounts of data is the telecommunications industry and particularly the cable television industry. Cable system operators typically maintain large databases containing a variety of subscriber, product and billing information. Typical classes of information managed by cable companies include subscriber accounts, available products and their pricing structure, physical assets and their functionality and marketing data. It is often desirable to distribute this information across a network of databases whether or not they are located at the same physical location.

The processing requirements for cable based systems can be staggering. For example, it may be necessary to provide 24 hour a day, 7 day a week service for a subscriber base of millions or tens of millions of subscribers. In addition, such a system may be called upon to execute hundreds or thousands of transactions per second (UPS). In addition, such systems may be required to support thousands of interactive users operating client terminals (e.g. Customer Service Representatives (CSRs)) many of which may be concurrent users. It is farther anticipated that the average customer record may soon be on the order of 15 kilobytes requiring a total database capacity of about 225 Gigabytes (assuming 15 million subscribers).

A typical prior art distributed database system that may be employed by a system operator includes a plurality of transaction generators or terminals which may be operated by CSRs to acquire access to data contained within the system. Each of the transaction generators communicates either directly or through a communications controller with a particular associated server or servers. Communication techniques and protocols which are known in the art are employed to allow the transaction generators to communicate with the servers. For example, Etherne.TM. may be used when both client and server are PC-based processors.

In prior systems, difficulty arises when access to data residing at differing locations is required. This places a burden on the CSR (or a transaction generator in general) because it may impose additional processing requirements to keep track of what data is accessible to a particular CSR and which is not. Additionally, if certain data is needed, but not accessible to a particular CSR, it may be necessary to determine where the data is located and which CSR may have access to that data.

An example of such a system exhibiting the drawbacks described above may include four data processing centers to support a national cable system operator. Each of four geographical regions in the United States (e.g. Northeast, Southeast, Midwest and West) may be supported by one of the four data processing centers. In such a case, all records for customers of the system operator who reside in Pennsylvania would be stored at the Northeast data center in its associated database. In the event that a particular Pennsylvania subscriber is at home and desires to receive information about his or her account the process is relatively simple. The subscriber may call in to a CSR operating a transaction generator connected with the Northeast database. The CSR, using the transaction processor, can simply generate a request for information regarding that subscriber. Alternatively, the subscriber may call in to an Automatic Response Unit (ARU) having an Automatic Number Indicator (ANI) interface and a similar request for information would be generated automatically.

The problem, however, arises when the same Pennsylvania subscriber also maintains a business account across the border in Ohio. Even though both accounts are serviced by the same system operator, a single call by the Pennsylvania/Ohio subscriber will not permit him or her to receive information about both accounts. This is because the Ohio account information will be located at and serviced by the Midwest data center. Since the transaction processor at the Northeast data center has no connection to the Midwest data base and since the transaction processor at the Midwest data center has no connection to the Northeast data base, the subscriber is forced to first call the Northeast data center for information about the residential account and then the Midwest data center for information about the business account. In addition, this subscriber is likely to receive two separate billing statements, one from each data center.

An additional drawback with this hypothetical system becomes evident when it is necessary to obtain system wide data. For example, a system operator may desire to retrieve data based upon subscriber demographics. Suppose, for example, the marketing department wishes to generate an alphabetical list of the names and addresses of all subscribers, system wide, who are over the age of 30 and subscribe to ESPN. It is necessary, using the above described system, to seperately access data within each of the four regions. Once data from each of the regions is gathered, it is further necessary to merge the data originating from each of the regions to generate one comprehensive list. The problems which are illustrated in this example are exacerbated when more than four data processing centers are used.

The method of distribution of customer records in the above example is known in the art as horizontal data distribution. In the above case, each of the customer records is completely contained on one physical server while the whole of its associated database and the enterprise domain of all customers is spread across all servers. It is also possible to distribute data in a vertical manner wherein different aspects of a customer's account resides on different physical servers.

SUMMARY OF THE INVENTION

In view of these and other drawbacks of the prior art, there is a need for a distributed data base system capable of handling large numbers of transactions in a short period of time and in an efficient manner. It is further desirable that the system be flexible, expandable, and cost efficient.

It is therefore an object of the current invention to overcome the above described and other drawbacks of the prior art.

It is a further object of the current invention to provide a distributed database system capable of high speed transaction processing.

It is a yet further object of the invention to allow database access while eliminating the need for time consuming processes normally associated with such access.

It is a still further object of the invention to provide server selection based upon a rules base allowing fast and efficient access to distributed information.

It is an even further object of the present invention to provide a distributed database system in which particular servers may be designated for the servicing of requests based upon the nature or type of request to be serviced.

According to one embodiment of the invention, these and other objects of the invention are achieved through the use of at least one Data Directory Server (DDS) located between one or more transaction generators and one or more data servers. The DDS efficiently routes transactions and provides data location functions. The DDS provides high data availability, high on-line transaction rates, batch capabilities, scalability and maintainability. In particular, based upon internal rules and the particular transaction type, the DDS routes transactions to the appropriate server(s). Transactions are classified according to where they may be executed. Specifically, transactions may be classified as SPECIFIC, ANY or ALL. A SPECIFIC transaction must be processed at one or more specific servers irrespective of the accompanying arguments. An ANY transaction may be processed at any of the servers and selection is made psuedorandomly. An ALL transaction requires processing by each of the data servers.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram depicting the architecture of one embodiment of the Subscriber Management System of the present invention.

FIG. 2(a) is a context diagram indicating the general dataflow in the Subscriber Management System of the present invention.

FIG. 2(b) is a flow chart illustrating, in a broad sense, the processing of a client request in the system of the present invention.

FIG. 3 is a flowchart illustrating the RPC Handler Process in a preferred embodiment of the present invention.

FIG. 4(a) is a data flow diagram illustrating the server selection process.

FIG. 4(b) illustrates the steps in a preferred embodiment of the "ALL" processing scenario.

FIG. 5 is a diagram providing an example of records stored within the system of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 illustrates the system and architecture of one embodiment of the present invention. While the various aspects and embodiments of the invention are capable of use in various types of distributed database systems, for simplicity, the invention will be described in connection with a Subscriber Management System (SMS) 100 having a distributed database. Such system is useful for, among other things, cable system operations. However, the invention is not limited to this use. As shown in FIG. 1, the SMS 100 comprises a plurality of transaction generators 120 labeled 1 through N, where N=any integer. Each transaction generator 120 is connected via a two-way communication link 105 to one (or more) data directory servers (DDS) 150. The present invention may include any number of data directory servers 150, but includes at least one. Each data directory server 150 in turn is connected via a two-way communication link 165 to multiple data servers (DS.sub.A -Ds.sub.m) 160. Each data server 160 is in turn connected to one or more databases either as components of a single subsystem (processor and database) or through a two way communication link 135. Additionally, each DDS 150 is connected via a two-way communication link 130 to one or more cross reference servers X-ref.sub.1 -X-ref.sub.n, where N=any integer) 170.

FIG. 1 indicates a block of 1 through N, (where N=any integer) DDSs 150 representing DDS functionality within the SMS. It is to be understood that, although not shown, connections between transaction generators 120 and DDSs 150 as well as those between data servers 160 and DDSs 150 are preferably individual connections rather than to a grouping of DDSs. For example, Transaction Generator 1 is separately connected to each of the DDSs as is Data Server A. Alternatively, however, DDS functionality may be grouped with common connections to transaction generators 120 and/or data servers 160 as indicated in FIG. 1 so long as proper control between DDSs 150 is maintained.

Additionally, the SMS system 100 includes at least one control application 175 for communication between the DDS(s) 150 and a human operator and/or another SMS process. As will be discussed in more detail below, the control application 175 provides, among other functionality, a means for updating the internal rules used by the DDS(s) 150.

As described in more detail below, when a transaction is generated by a transaction generator 120 and sent to a data directory server 150, the data directory server 150 determines the appropriate server 160 for execution of the transaction. Preferably, this is accomplished by the DDS 150 consulting the internal rules and identifying the arguments associated with the transaction, as detailed below.

The SMS 100 of the present invention is designed to manage a very large number of OLTP transactions occurring within the system. The SMS 100 of the present invention provides users with the ability to query across the entire database from any client in the system. Similarly, each of the users may update data located anywhere within the SMS 100.

Client--Transaction Generator

The transaction generators 120 in the system of the present invention may be any devices capable of receiving input from a user and transmitting that input to the Data Directory Servers (DDSs) 150. This type of device is often referred to as a client and these terms are used interchangeably herein. These devices may be dumb terminals (i.e. incapable of performing local processing) or they may have various processing capabilities of their own. Examples of transaction generators include, without limitation, PC's, RISC-based workstations and local area networks. In typical applications, there will be a large number of transaction generators 120. Thus, the SMS 100 is designed as an open platform environment which is hardware independent. The transaction generators 120 may be homogeneous in terms of interface and operation or they may be heterogeneous. In other words, all transaction generators 120 may be of one type or there may be a variety of devices interacting with the DDSs 150. It is also possible to permit customer interaction with the SMS 100 through an ARU/ANI (Automated Interactive Voice Response Unit/Automatic Number Indicator) (not shown). In this case, much of the processing may be driven by the telephone number retrieved by the ANI when the customer calls into the system.

DDS

The DDSs 150 of the present invention function as the middle tier of a three tier client/server architecture. As illustrated in FIG. 1, more than one DDS 150 may exist within the SMS 100. In such case, each of the DDSs 150 has communication access to all of the other DDSs 150 as well as to each of the data servers 160. The DDSs 150 serve three primary functions. After receiving a client request, the selected DDS 150 first locates the appropriate server 160 for execution of the request, it then submits the client request to the selected server and finally the DDS 150 returns the result to the submitting client 120.

Transaction generators 120 requesting information from the SMS databases must connect to a DDS 150 prior to accessing data. Through the use of internal rules, the DDSs 150 determine where a remote procedure should run in order to complete processing of a transaction. Access to the DDSs 150 may be efficiently implemented through the use of remote procedure calls (RPCs) which are identified in tables internal to the DDS 150. Any of a large number of standards for such RPCs may be used with the current invention.

The DDS(s) 150 are preferably open server applications that provides a mechanism to direct any data request associated with a generated transaction to a data server 160 that can service the transaction generators' requests. Specifically, the DDSs 150 may be open servers comprising the same or similar hardware as the data servers 160 of the present invention. Alternatively, the DDSs 150 may be configured differently from the data servers 160. The DDSs 150 function to analyze the client's data request transaction and, based upon the transaction type and a set of rules, directs the request to the appropriate data server 160. The types of transactions which are received at the DDSs 150 are based upon a set of stored procedures recognizable to the DDSs 150 and available to the transaction generators 120.

The DDSs 150 communicate with a plurality of data servers 160 each accessing one or more storage devices. In a preferred embodiment of this invention the data servers 160 are Sybase SQL Servers which execute Sybase remote procedure calls. This invention is not, however, necessarily limited thereto and the servers may be of any type so long as the stored procedures are designed for processing by the particular server and the associated database which are selected. It is possible to employ any number of servers 160, transaction generators 120 and DDSs 150 in the SMS 100 of this invention so long as the proper number of communication channels can be supplied and supported.

As noted above, more than one DDS 150 may exist in the system to provide scalable execution of these functions, each such DDS 150 being in communication with all transaction generators/clients 120 and all servers 160. In an embodiment with multiple DDSs 150, clients 120 are connected with one DDS 150 according to a pre-determined method.

Prior to discussing the specifics of database transactions according to the method and system of this invention, it is necessary to understand that the DDSs 150 preferably operate according to a limited number of event handlers responsible for processing the requests generated by the transaction generators 120 as well as internal requests generated as a result of DDS processing itself. The event handlers are as follows:

1. Start Handler--The start handler provides a convenient and central location for installing any other event handler routines, building any tables necessary for processing client requests and for installing any other services that the DDS requires for its functionality.

2. Stop Handler--The stop handler is executed when a request to shut down the system has been received through a particular request or as a result of certain system conditions.

3. Connect Handler--The connect handler is executed whenever a client connects to the DDS.

4. Disconnect Handler--The disconnect handler is executed whenever a client terminates an active connection to the DDS.

5. Language Handler--The language handler is executed whenever a client application issues a language statement to the DDS. The language handler in the DDS does nothing since all client requests are required to be either registered procedure calls or remote procedure calls.

6. RPC Handler--The Remote Procedure Call handler carries the bulk of the load shouldered by the DDS and is the most important handler for purposes of this discussion. Any client request which is not registered in the DDS registered procedure table will generate an RPC handler event where the request is analyzed by the RPC event handler and acted upon accordingly.

7. Error Handlers--Several error handlers are installed in the DDS application to provide information on any failure from the client, server and client/server components of the DDS. All error messages are logged in the DDS.

8. Attention Handlers--An attention handler is installed to handle disconnects from a client application. The DDS has been set up to cause all client disconnects to generate an attention event in order to determine if the client application has interrupted its connection to the DDS.

The functionality comprising the operation of the DDS can be categorized into three separate classes--the main function, the local DDS registered procedures and the utility functions. The main () function provides the entry point for all executable C programs. Note that although the preferred embodiment is formulated using the C and C++ languages, the particular invention described herein is by no means limited to such a design. The error handlers and the start handler are installed in the main function body. These include a set of routines which serve to parse input parameters and configuration file attributes in order to set up any DDS properties. The network listening function is spawned in the main function body and sleeps until the DDS application is terminated either normally or abnormally.

The DDS application is dependent on several global data tables. These global tables are used to control the navigational decisions that the RPC Handler needs to direct the client's data requests to the appropriate data server in order to complete the data request. A more detailed discussion of the global tables, including construction, maintenance and use, follows below.

The Open Server Install Registered Procedures, os.sub.-- install.sub.-- reg.sub.-- procs (), function provides a central installation point for all registered procedures on the DDS and is grouped in the start handler classification. Service requests originating at the client that are not identified as a registered procedure, are treated as remote procedure calls and are handled by the RPC Handler. All of the event handlers and supporting system functions provide a trace log of activities in a locally maintained log file. This file is preferably truncated every time the DDS application is started.

Data Servers

The data servers 160 maintain the customer data and are accessible by each of the transaction generators 120 through a DDS 150. In a typical implementation, the data servers 160 are SQL devices which are capable of executing the RPCs transmitted by a DDS 150.

The databases making up the enterprise can be either homogenous or heterogeneous. In a homogeneous environment, particular protocols for accessing each of the databases are consistent throughout the enterprise. Conversely, in a heterogeneous environment, the particulars of database access vary within the enterprise. In a heterogeneous environment, it is often desirable, however, to render any differences in requirements within the enterprise transparent to user working at the client site. That is, a user should not be aware of any database heterogeneity and a user request should be processed in a standard manner across all resources.

The databases which are accessed in a distributed system may all be located together or they may be physically apart. They may be at the client location or they may be at an alternate site. Databases may be relational databases such as SYBASE (a trademark of Sybase, Inc.) or they may be as simple as a series of flat files.

Control Application

Returning to FIG. 1, it can be seen that the DDSs 150 interface with a control application 175. The control application 175 functions to allow a system operator to store, update and modify stored procedures available to transaction generators 120. This is typically accomplished by downloading the update to the X-Ref Server 170 which loads the new rules base into the DDSs 150 at DDS startup. This will be discussed in more detail below.

X-Ref Servers

The SMS system also includes one or more X-Ref Servers 170. As will be discussed in further detail below, the X-Ref Servers 170 function as a resource available to the DDSs 150 for determining where specific data resides in the system and for storing the rules base which is loaded into the DDSs 150 at DDS start-up. The X-Ref Servers 170 contain a variety of global tables which are continually updated as data is added, updated and deleted within the system.

Turning now to FIG. 2(a) and 2(b), a context diagram and flow chart, respectively for the SMS system 100 as controlled and regulated by the DDS function 150 are provided. In a preferred embodiment, the DDSs 150 access the XRef Server(s) 170 at startup to access database information necessary for the operation of the DDSs 150. After the start-up tasks are complete, normal client requests may be processed by the DDSs 150. Alternatively, the DDSs 150 may access the XRef Server(s) 170 (or any other device containing the required data) as requests are submitted to the DDSs 150.

Client requests are initiated at the transaction generators 120 and transmitted to a DDS 150. Once it has received the data request, the DDS application consults the DDS Server Table (a global table) which identifies all of the available and accessible data servers 160. There is also provided an XRef Server Table (global) which identifies all known and accessible XRef Servers 170. An additional global table is the Error Message Handler Table which maintains all error handler messages. All of the global tables defined in the DDS 150 provide feature functionality to support the access related to these tables.

FIG. 2(a) also shows the various transaction generators 120 connected to the DDS 150. Transaction generators 120 make requests for reads, writes and updates through the DDS 150. As discussed above, once a request is received, the DDS 150 determines the set of potential data servers which may execute the request and psuedorandomly selects one or more servers from that set for servicing. Alternatively, various, non-random and semi-random methods for selecting the subset of potential data servers may be used. Examples of such methods include those relating to current server loads (load balancing) and those relating to queuing theory in general. The subset of servers which are available to process the request may be determined in one of two ways as discussed above. In a first embodiment, global tables are loaded from the XRef Server 170 into internal DDS memory at DDS startup. In a second embodiment, no such loading occurs at startup--rather, upon receiving a client request, the DDS 150 submits a request to the XRef Server 170 in order to retrieve the necessary data. In either embodiment, the DDS 150 has available to it the necessary rules base and other data which is required to determine the type of transaction (including the data required and the locations of that data) and to select the appropriate data server(s) 160 for processing the transaction. Next, the request is submitted to the selected data server(s) which process the request and returns a result set to the DDS 150 which may then perform additional operation(s) on the data prior to passing the final result set back to the client 120. Alternatively, the result set may pass through the DDS 150 to the client 120 without any additional processing on the part of the DDS 150. The latter situation is generally termed "pass-through mode".

After a request has been serviced and the result set has been returned to the client 120, the DDS 150 may receive another request and process it in accordance with the above procedure. In such an embodiment, the DDS 150 does not begin processing a new request until it has completed processing of the prior request. In another and preferred embodiment, a single DDS 150 processes multiple client requests concurrently exploiting the availability of numerous resources for processing large numbers of transactions.

Additionally, provision is made for the DDS 150, and ultimately the SMS 100, to interface with external components and processes 125. Further discussion regarding these capabilities is included below.

As mentioned above, the DDS application 150 maintains several global tables which are constructed and supported by classes. These classes are next discussed.

The first class to be discussed is the Server Table Class. The Server Table Class is a global class. This class references all available servers in the SMS system 100. The Server Table class supports two tables that are constructed from DDS data files. The first table, the DDS Server Table, identifies all available data servers that are accessible by the DDS application 150. The second table supported by the Server Table Class is the XRef Server Table, which refers to all available XRef Servers. Both of the Server Tables provide server names, logins and password information to the DDS 150 so that it may access any server 160 within the SMS system 100.

The Server Table class employs information structure pointers to support the list of available servers specified by the class instantiation. The class provides methods to randomly retrieve the next available server in the table or to select a specific server in the table. In addition, it is possible to retrieve the user ID and password associated with a server as well as the number of servers available.

The XRef Server Table is built on the instantiation of the Server Table Object through the applicable DDS data file. The Server Tables are built based on the server names and in the preferred embodiment the initial ordering is alphabetical by server name. It is of course possible to implement other ordering schemes for building the XRef Server Table.

The DDS Server Table is a global table which is also constructed from the DDS data file. The Server Table Class definition of the preferred embodiment is given below:

    ______________________________________
    class ServerTbl
    private:
    SrvInfo   *.sub.-- server;
                             //server information
                              structure
    CS.sub.-- INT
              .sub.-- next;    //next server name
    CS.sub.-- INT
              .sub.-- serverCnt;
                                //server count
    protected:
              ServerTbl();
    public:
              ServerTbl(CS.sub.-- CHAR*,
              constCS.sub.-- CHAR*);
              .about.ServerTbl();
    CS.sub.-- CHAR
              *GetNext();
    CS.sub.-- CHAR
              *GetUID();     //inline
    CS.sub.-- CHAR
              *GetPswd();    //inline
    CS.sub.-- INT
              GetCnt();      //inline
    CS.sub.-- CHAR
              *GetSpecific(CS.sub.-- INT i);
                             //inline
    CS.sub.-- VOID
              UpdateTbl(CS.sub.-- CHAR*,
              const CS.sub.-- CHAR*);
    }
    ______________________________________

    ______________________________________
    class SrvName
    private:
    ProcElem  *.sub.-- p;
    CS.sub.-- INT
              .sub.-- arg Val;
    CS.sub.-- INT
              .sub.-- curElem;
    public:
              SrvName(ProcElem*,CS.sub.-- VOID**);
              .about.SrvName();
    SrvElem   *GetNext(SrvElem*&);
    SrvName&  operator=(const SrvName&);
    CS.sub.-- INT
              GetSrvCnt();
    CS.sub.-- INT
              GetSrvTyp();
    };
    ______________________________________

                  TABLE 1
    ______________________________________
    SERVER NAME CLASS FUNCTIONS
    * SrvName :: SrvName(ProcElem *.sub.-- p, void **argList)
    Assign procedure element .sub.-- p to SrvName class variable.
    If the argList a is not NULL
    Assign the argument position value to the class variable
    initialize the current element class variable to 1
    * SrvName :: GetNext( )
    if (-P-> firstSrv) // GROUP
    if((.sub.-- p->dtpCode ==ALL)&&
    (.sub.-- curElem<=.sub.-- p>elemCnt))
            curSrv = .sub.-- p->firstSrv[.sub.-- curElem - 1]
            ++.sub.-- curElem
    else if ((.sub.-- p ->dtpCode == ANY) && (.sub.-- curElem == 1))
            rNum = .sub.-- p->firstSrv[GetRandom( )]
            ++.sub.-- curElem
    else if ((.sub.-- p ->dtpCode == SPECIFIC) &&
    (.sub.-- curElem == 1))
            curSrv = .sub.-- p->firstSrv[.sub.-- curElem - 1]
            ++.sub.-- curElem
    else
            retrieval is complet, return a NULL pointer value
            reset .sub.-- curElem to 1
    else if(.sub.-- p -> firstRule)
    for i = 0; i < .sub.-- p->firstCnt; i++
            if .sub.-- argVal == NULL
              set curSrv to NULL
              the parameter for this stored procedure
              is missing
            if .sub.-- argVal <= .sub.-- p -> firstRule[i] -> high.sub.-- val
            &&
              .sub.-- argVal >= .sub.-- p -> firstRule[i] -> lowVal &&
              .sub.-- curElem == 1
              curSrv = .sub.-- p->firstSrv[i].servers
              curSrv -> dbName = .sub.-- p->dbName
              increment .sub.-- curElem
              break out of for loop
            else if .sub.-- curElem > 1
              set curSrv to NULL
              reset .sub.-- curElem to 1
              break out of for loop
            else
              continue
    end for loop
    else
    set curSrv to NULL
    there is a problem with the XRef Data Tables
    return curSrv;
    * SrvName :: GetSrvCnt( )
    return .sub.-- p->firstCnt
    *SrvName :: GetSrvTyp( )
    return .sub.-- p->dtp.sub.-- code
    ______________________________________

    ______________________________________
    struct SrvElem
    char       SrvName[MAXNAME];
    char       warmSrv[MAXNAME];
    char       grpName[MAXNAME];
    int        srvConn;
    int        warmConn;
    };
    struct RuleElem
    {
    char       ruleName[MAXNAME];
    int        lowVal;
    int        highVal;
    char       srvName[MAXNAME];
    SrvElem    *servers
    };
    struct ProcElem
    {
    char       procName[MAXNAME];
    char       grpName[MAXNAME];
    char        ruleName[MAXNAME];
    char        srvName[MAXNAME];
    char        dbName[MAXNAME];
    PROC.sub.-- TYPE
               pType;
    DTP.sub.-- CODE
                dtp;
    int         argPos;
    int         firstCnt;
    SrvElem     *firstSrv;
    RuleElem    *firstRule;
    };
    ______________________________________

    ______________________________________
    class XRefDataTbl
    private:
    ProcElem     *.sub.-- procList;
    SrvElem      *.sub.-- srvList;
    RuleElem     *.sub.-- ruleList;
    CS.sub.-- INT
                 .sub.-- procCnt;
    CS.sub.-- INT
                 .sub.-- srvCnt;
    CS.sub.-- INT
                 .sub.-- ruleCnt;
    protected:
    XRefDataTbl();
    public:
    XRefDataTbl();
    .about.XRefDataTbl();
    CS.sub.-- INT
                 GetProcCnt();
                             //inline
    CS.sub.-- INT
                 GetSrvCnt();
                               //inline
    ProcElement  *GetProcList();
                               //inline
    CS.sub.-- RETCODE
                 GetServer(CS.sub.-- CHAR*,CS.sub.-- VOID**,
                 SrvName*);
    CS.sub.-- RETCODE
                 UpdateTbl(CS.sub.-- CHAR*,CS.sub.-- CHAR*,
                 CS.sub.-- CHAR*);
    CS.sub.-- RETCODE
                 RunRpc(CS.sub.-- CONNECTION*,CS.sub.-- CHAR*,
                 CS.sub.-- INT);
    CS.sub.-- RETCODE
                 BldList();
    };
    ______________________________________

                  TABLE 2
    ______________________________________
    XREF DATA TABLE CLASS FUNCTIONS
    The object constructor is as follows:
    XRefDataTbl::XRefDatatbl( )
    initialize the procedure, server, and rule counts to zero
    if(UpdateTbl(CS.sub.-- CHAR *server, CS-CHAR *uid,
    CS.sub.-- CHAR *pswd)!= CS .sub.--  SUCCEED)
    exit out of the function
    The UpdateTbl function represents the XRef data table update
    function that builds the XRef data tables from the XRef Server.
    XRefDataTbl::UpdateTbl(CS-CHAR *server, CS..sub.-- CHAR *uid,
    CS-CHAR *pswd);
    Set up the client interface to the XRef Server
    This is a standard client library interface set up
    Run the stored procedure "lp.sub.-- get.sub.-- srv-cnt" to retrieve the
    number of servers stored in the database.
    if it fails, there is a problem with the XRef Table Data
    Run the stored procedure "lp.sub.-- get.sub.-- rule.sub.-- cnt" to
    retrieve the
    number of rules stored in the database.
    if it fails, there is a problem with the XRef Table Data
    Run the stored procedure "lp.sub.-- get.sub.-- proc.sub.-- cnt" to
    retrieve the
    number of procedures stored in the database.
    if it fails, there is a problem with the XRef Table Data
    Allocate sufficient memory to store the number of rows for
    the server list.
    Run the stored procedure "lp.sub.-- get.sub.-- srv.sub.-- list"
    to retrieve the data from
    the SERVER.sub.-- GROUP and SERVER tables.
    Allocate sufficient memory to store the number of rows for
    the rule list.
    Run the stored procedure "lp.sub.-- get.sub.-- rule.sub.-- list"
    to retrieve the data from the
    RULE-BOUNDARY and SERVER tables.
    Allocate sufficient memory to store the number of rows for
    the procedure list.
    Run the stored procedure "lp.sub.-- get.sub.-- proc.sub.-- list"
    to retrieve the data from
    the PROCEDURE table.
    Integrate the lists by calling the BldList( ) function
    Exit and clean up the client application
    };
    The Build List function builds the lists such that the three XRef data
    tables are interlinked to provide a quick access to the desired server
    name based on the stored procedure issued by the user.
    XRefDataTbl::BldList( )
    For every row returned from "lp-get.sub.-- proc.sub.-- cnt`
    link the structure
            if procList->pType == GROUP
            sequentially search srvList for srvList->
             grpName == procList->grpName
            store first srvList element in procList->firstSrv
            assign procList->firstRule = NULL
            initialize first count to zero
            sequentially search srvList and count the number of
             servers supporting the server group
            store the count of the number of server in
             procList->firstCnt
    else if procList->pType == RULE
            sequentially search ruleList for
            srvList->ruleName==procList->ruleName
    store first ruleList element in procList->firstRule
    assign procList->firstSrv = NULL
    sequentially search ruleList and count the number of
            rules supporting the server group
    store the count of the number of rules in
            procList->firstCnt
            sequentially search server List for server name
             assign server pointer to server list element
    else // procList->pType == SPECIFIC
            sequentially search server list for server name
              assign firstSrv to the server list element
              assign NULL to firstRule
              assign 1 to firstCnt
              break out of for loop
    };
    The Run RPC function issues the command to the remote data
    server and processes the results.
    XRefDataTbl::RunRpc(CS-CONNECTION *conptr,
    CS.sub.-- CHAR *cmd, CS.sub.-- INT cmdType)
    {
    Allocate the command structure
     Initiate the command
    Send the command
    Process the results based on the command type
    This functionality is specific to the type of command issued
    Drop the command structure
    }
    The get server function searches the stored procedure list for a
    particular stored procedure and creates a server name class object
    to point to the first server supporting that stored procedure.
    CS.sub.-- RETCODE
    XRefDataTbl::GetServer(char *procname, void **argList,
    SrvName *server)
    {
    Perform a binary search of the procedure list for the
    current stored procedure if it fails to get an entry,
    return CS - FAIL;
    Create server name object server for the procName and argList
    Assign server name to return parameter
    Return CS.sub.-- SUCCEED;
    }
    ______________________________________

    ______________________________________
    class ClntUserData
    private:
    FMT.sub.-- CTL*  .sub.-- fmtCTL;
    Ucon*            .sub.-- ucon;
    public:
    ClntUsrData(int  numSrvs,
                     LoginData & loginData,
                     CmdConPool*cmdConPoolPtr);
    .about.ClntUsrData();
    virtual Ucon*    GetUcon(); //inline
    virtual FMT.sub.-- CTL
                     *GetFmtCtl();
                                //inline
    }
    ______________________________________

    ______________________________________
    class TopRPCList: public TopList
    protected:
    virtual COMPARE.sub.-- CD CompareFunc(void *)
    public:
            TopRPCList(SRV.sub.-- PROC*srvProcPtr,
              ProcElement* rpcListPtr,
              CS.sub.-- INT rpcListSize,
              CS.sub.-- INT topListSize);
            .about.TopRPCList() {}
    };
    ______________________________________

    ______________________________________
    Stored Procedure Name - LP.sub.-- GET.sub.-- PROC.sub.-- LIST - Retrieves
    a list
    of procedure names and related information.
    Logical Table Name - procedure.sub.-- list
    Location - XRef Server
    Procedure Type - Group
    Database - xref
    Input Parameters - Nothing or a valid stored procedure name
    Output Values - A list of the attributes of the store procedure(s)
    Procedure Text - As follows:
    create procedure lp.sub.-- get.sub.-- proc.sub.-- list@pname char(30) =
    "%"
    as
    begin
    select     procedure.sub.-- name,
             group.sub.-- name,
             procedure.sub.-- type,
             dtp.sub.-- code,
             argument.sub.-- position,
             rule.sub.-- name,
             server.sub.-- name,
             database.sub.-- name
    from         procedure list
    where      procedure.sub.-- name like @pname
    sort by    procedure.sub.-- name
    end
    Stored Procedure Name - LP.sub.-- GET.sub.-- RULE.sub.-- LIST -
    Retrieves a list of rule names and related information.
    Logical Table Names - rule.sub.-- boundary and server.sub.-- list
    Location - XRef Server
    Procedure Type - Group
    Database - xref
    Input Parameters - Nothing or a valid rule name
    Output Values - A list of the attributes of the store procedure(s)
    Procedure Text - As follows:
    create procedure lp.sub.-- get.sub.-- rule.sub.-- list @rule.sub.-- name
    char(30) = "%"
    as
    begin
    select     rule.sub.-- name,
               low.sub.-- value,
               high.sub.-- value,
               r.server.sub.-- name
    from         rule.sub.-- boundary r, server.sub.-- lists
    where      r.server.sub.-- name = s.server.sub.-- name
               and
               rule.sub.-- name like @rule.sub.-- name
    sort by    rule.sub.-- name, low.sub.-- value
    end
    Procedure Name - LP.sub.-- GET.sub.-- SEV.sub.-- LIST - Retrieves a list
    of server
    names and related information.
    Logical Table Name - server.sub.-- list and server.sub.-- group
    Location - XRef Server
    Procedure Type - Group
    Database - xref
    Input Parameters - Nothing or a valid stored procedure name
    Output Values - A list of the attributes of the store procedure(s)
    Procedure Text - As follows:
    create procedure lp.sub.-- get.sub.-- server.sub.-- list @sname char(30)
    = "%"
    as
    begin
    select     server.sub.-- name,
               warm.sub.-- server,
               s.group.sub.-- name
    from         server.sub.-- list s, server.sub.-- group sg
    where      s.group.sub.-- name = sg.group.sub.-- name
               and
               s.server.sub.-- name like @sname
    sort by    s.group.sub.-- name, s.server.sub.-- name
    end
    LP.sub.-- GET.sub.-- PROC.sub.-- COUNT - Retrieves a count of the number
    of
    procedures
    stored on the XRef Database.
    Logical Table Name - procedure.sub.-- list
    Location - XRef Server
    Procedure Type - Group
    Database - xref
    Input Parameters - Nothing
    Output Values - A count of all the store procedures
    Procedure Text - As follows:
    create procedure lp.sub.-- get.sub.-- proc.sub.-- cnt
    as
    begin
    select     count(*)
    from         procedure.sub.-- list
    end
    LP-GET.sub.-- RULE.sub.-- COUNT - Retrieves a count of the number of
    rules
    stored on the XREF Database.
    Logical Table Name -server.sub.-- list and rule.sub.-- boundary
    Location - XRef Server
    Procedure Type - Group
    Database - xref
    Input Parameters - Nothing
    Output Values - A count of all the rules
    Procedure Text - As follows:
    create procedure lp.sub.-- get.sub.-- rule.sub.-- count
    as
    begin
    select     count(*)
    from         rule.sub.-- boundary r, server.sub.-- list s
    where      r.server.sub.-- name = s.server.sub.-- name
    end
    LP.sub.-- GET.sub.-- SERVER.sub.-- COUNT - Retrieves a count of the
    number of servers
    stored on the XRef Database.
    Logical Table Name - server.sub.-- list and server.sub.-- group
    Location - XRef Server
    Procedure Type - Group
    Database - xref
    Input Parameters - Nothing
    Output Values - A count of all the servers
    Procedure Text - As follows:
    create procedure lp.sub.-- get.sub.-- server.sub.-- count
    as
    begin
    select     count(*)
    from         server.sub.-- list s, server.sub.-- group sg
    where      s.group.sub.-- name = sg.group.sub.-- name
    end
    LP.sub.-- GET.sub.-- SRVGRP-COUNT-Retrieves a count of the number of
    server
    groups stored on the XRef Database.
    Logical Table Name - server-group
    Location - XRef Server
    Procedure Type - Group
    Database - xref
    Input Parameters - Nothing
    Output Values - A count of all the server groups
    Procedure Text - As follows:
    create procedure lp.sub.-- get.sub.-- srvgrp.sub.-- count
    as
    begin
    select     count(*)
    from         server.sub.-- group
    end
    ______________________________________

• Inventors
  Rierden, William; Marusin, Mark; Gollob, David;
• Assignee
  CSG Systems, Inc. (Englewood, CO)
• Published
  Nov-2-1999
• Current US Classes:
  340/825.52
  379/114.25
  707/10
  707/100
  707/3
  707/4
  709/202
  709/203
• Application #
  405766
• International Classes
  G06F 017/30
• Field of Search
  395/600 395/200 395/275 395/603 395/604 395/610 395/611 395/200.31 395/200.33 340/825.52 379/115
• Examiner
  Black; Thomas G.
• Agent
  Baker & McKenzie
• US Patent References:
  4651279
  4694396
  4714996
  4757267
  4853843
  4858120
  4864497
  4875206
  4882674
  4893302
  4894824
  4896319
  4897874
  4899333
  4922486
  4953204
  5005122
  5113496
  5163131
  5167035
  5200993
  5218676
  5218697
  5222120
  5230072
  5245608
  5247664
  5253342
  5257369
  5263158
  5263165
  5265250
  5274806
  5276879
  5276901
  5283731
  5287103
  5287461
  5289371
  5291550
  5307495
  5313581
  5313646
  5325290
  5325527
  5329619
  5341474
  5341476
  5341477
  5345556
  5345586
  5347632
  5353412
  5355453
  5404523
  5414812
  5446886
  5452450
  5459860
  5463774
  5469497
  5481700
  5551027
  5581749