Database access system having time-out mechanism

[0002] 1. Field of the Invention

[0003] The present invention relates to a database access system for use in accessing a plurality of distributed databases from a plurality of client terminals; and a computer program product, which contains an application program for the same.

[0004] This application is based on patent application No. Hei 10-146371, filed in Japan, the content of which is incorporated herein by reference.

[0005] 2. Description of the Related Art

[0006] FIG. 5 is a block diagram, showing a structure of a conventional database access system. The database access system in this diagram exhibits a three-layer structure, comprising a client layer, an intermediate layer, and a database layer.

[0007] In the client layer shown in FIG. 5, client terminals (computers) 30₁-30₃installed at the client site are respectively connected to a network 3. The network 3 can be, for example, an internet. Furthermore, each of the client application programs 31_1-313executed by the respective client terminal 30_1-303is recorded into the memory portion of each respective client terminal 30₁-30₃.

[0008] These client application programs 31₁-31₃are programs for requesting a service with regard to an application server 34, described hereinafter, and for receiving the results of said service.

[0009] In addition, in the database layer, the database servers 32₁-32₃are computers which store the databases 33₁-33₃, delivered via the network 3. Each respective database 33₁-33₃is recorded into the memory portion of the corresponding database server 32₁-32₃. These databases 33₁-33₃are all identical in type.

[0010] Furthermore, in the intermediate layer, the application server 34 is a computer which accommodates the client terminals 30₁-30₃via the network 3, and is connected to the database servers 32₁-32₃. The application server 34 processes service requests from each of the client terminals 30₁-30₃. Additionally, the server application program 35, run by the application server 34, is stored into a memory portion of the application server 34.

[0011] The server application program 35 is a program for performing the above-mentioned services, an example of which includes accessing the databases 33₁-33₃, described later. In other words, the application server 34 accesses the databases 33₁-33₃, based on a service request from a client terminal 30₁-30₃, and performs transactions such as updating and reading data, etc. Herein, data update is performed by means of a two-phase commit, comprising the two phases of temporary updating and permanent updating.

[0012] In the application server 34, the transaction processing (TP) monitor 36 performs distributed transaction processing, or more concretely, accesses the databases 33₁-33₃. Hereinafter, distributed transaction processing represents the process of accessing the distributed databases 33₁-33₃.

[0013] Herein, the distributed transaction standard employs a TX/XA interface using X/Open. FIG. 6 is a block diagram, showing a reference model of the above-mentioned distributed transaction processing; and FIG. 7 is a block diagram, showing a TX/XA interface using X/Open. In FIGS. 6 and 7, the corresponding parts to FIG. 5 have the same reference numbers.

[0014] In FIG. 6, the transaction manager 37 corresponds to the transaction processing monitor 36 shown in FIG. 5, and possesses an interface with the server application program 35.

[0015] The resource mangers 38₁-38₃are, individually, managed by the server application program 35 and the transaction manager 37, and correspond, respectively, to the databases 33₁-33₃shown in FIG. 5. Herein, the resource managers 38₁-38₃interface with both the transaction manager 37 and the server application program 35.

[0016] In addition, in FIG. 7, the resource manager 38₁, (see FIG. 6) is a general term for the database 33₁, (see FIG. 5) and the communication resource manager 39₁. The communication resource manager 39₁controls communication between other systems (not shown) and the database server 32₁, via the network 44. Herein, FIG. 7 shows only a structure of the resource manager 38₁, shown in FIG. 6; however, structures of the resource managers 38₂and 38₃, shown in FIG. 6, are identical to the structure of the resource manager 38₁, shown in FIG. 7.

[0017] The TX interface 40 is an interface between the server application program 35 and the transaction manager 37. The XA interface 41 is an interface between the transaction manager 37 and the database 33₁. The XA+interface 42 is an interface between the transaction manager 37 and the communication resource manager 39₁. The application/resource manager interface 43 is an interface between the server application program 35 and the database 33₁.

[0018] As described above, a conventional database access system possesses four interfaces: the TX interface 40; the XA interface 41; the XA+interface 42; and the application/resource manager interface 43. Further, the database 33₁, is accessed by each of the server application program 35 and the transaction manager 37, via another interfaces such as the XA interface 41 and the application/resource interface 43, respectively.

[0019] In the following, the operation of the above-mentioned conventional database access system is described.

[0020] In the descriptions below, an example case in which a client terminal 30₁, shown in FIG. 5, requests the application server 34 for a service, such that the application server 34 updates the databases 33₁, and 33₂, in order to respond to the service request.

[0021] In FIG. 5, when service request data is inputted from the client terminal 30₁, to the application server 34 via the network 3, the application server 34 performs the following processing by means of running the server application program 35.

[0022] That is, the application server 34 accesses the database servers 32₁, and 32₂, in order to temporarily update the databases 33₁, and 33₂. Concretely, the server application program 35 (i.e., the application server 34) provides the command for temporarily updating the database to the transaction manager 37 via the TX interface 40. As a result, the transaction manager 37 temporary updating of the above-mentioned data, by means of accessing the databases 33₁, and 33₂via the XA interface 41.

[0023] Subsequently, after this temporary updating is completed, under normal circumstances, the server application program 35 (i.e., the application server 34) outputs the control data for performing permanent updating of the databases 33₁, and 33₂, to the transaction manager 37 via the TX interface 40. Accordingly, the transaction manager 37 performs permanent updating of the data, by means of accessing the databases 33₁and 33₂via the XA interface 41.

[0024] A conventional database access system is designed to access a plurality of the databases 33₁-33₃in parallel, by means of a single transaction manager 37 (i.e., transaction processing monitor 36). This causes in an extremely complex structure for both the transaction manager 37 (i.e., transaction processing monitor 36) and the TX interface 40.

[0025] Additionally, a conventional database access system is designed to have four interfaces: the TX interface 40; the XA interface 41; the XA+interface 42; and the application/resource manager interface 43, shown in FIG. 7, which results in a large number of interfaces.

[0026] In summary, a conventional database access system is disadvantageous from the viewpoint of its high costs secondary to the above-mentioned complex structure and large number of interfaces.

[0027] Moreover, a conventional database access system accesses a plurality of the databases 33₁-33₃by means of a single transaction manager 37 (i.e., the transaction processing monitor 36). Accordingly, it is absolutely necessary for the databases 33₁-33₃to be identical in type.

[0028] Thus, conventional database access systems are also disadvantageous in being unable to handle different types of databases.

[0029] In consideration of the above-mentioned, a object of the present invention is to provide an economical database access system possessing a simple structure, which can handle different types of databases.

[0030] According to the present invention, the above-mentioned object is achieved by means of a database access system comprising: a plurality of database servers, each of which accommodates a database; an application server which is connected to each of the database servers; wherein the application server comprises a plurality of local transaction managers, each of which corresponds to the databases, and processes transactions for updating these databases; and a distributed transaction manager which individually provides commands for database updating to each of the local transaction managers.

[0031] According to the present invention, a plurality of local transaction managers which correspond to a plurality of databases are installed in each application server, and these local transaction managers process, individually, an accessing transaction (i.e., updating transaction). Accordingly, according to the present invention, when compared to a conventional database access system, it is possible to simplify processing control, which in turn simplifies the overall system structure, thereby lowering costs.

[0032] FIG. 1 is a block diagram, showing a structure of the database access system according to an embodiment of the present invention.

[0033] FIG. 2 is a block diagram, showing a reference model of distributed transaction processing in the database access system according to an embodiment of the present invention.

[0034] FIG. 3 is a block diagram, showing interfaces of the database access system according to an embodiment of the present invention.

[0035] FIG. 4 is a diagram showing the sequence of the database access system according to an embodiment of the present invention.

[0036] FIG. 5 is a block diagram, showing a structure of a conventional database access system.

[0037] FIG. 6 is a block diagram, showing a reference model of distributed transaction processing in a conventional database access system.

[0038] FIG. 7 is a block diagram, showing a TX/XA interface using X/Open in a conventional database access system.

[0039] The following embodiments do not limit the invention with regard to the claims. In addition, all the combinations of the characteristics described in the embodiments are not necessarily essential to achieve the object of the present invention.

[0040] In the following, embodiments of the present invention are described with reference to the figures. FIG. 1 is a block diagram, showing a structure of the database access system according to an embodiment of the present invention. In FIG. 1, a database access system is shown which possesses a three-layer structure comprising a client layer, an intermediate layer, and a database layer.

[0041] In the client layer shown in FIG. 1, the client (computer) terminals 1₁-1₃are, respectively, installed at the clients' sites, and connected to a network 3. The network 3 can be, for example, an internet. Each of the client application programs 2₁-2₃run by the respective client terminal 1₁-1₃is recorded into the memory portion of each respective client terminal 1₁-1₃.

[0042] These client application programs 2₁-2₃are programs designed to request the application server 6, described hereinafter, for a service, and to receive the result of this service.

[0043] In addition, in the database layer, the database servers 4₁-4₃are computers which house the databases 5₁-5₃, delivered via the network 3; and each of the databases 5₁-5₃is recorded into the memory portion of the corresponding database servers 4₁-4₃. These databases 5₁-5₃can be identical or different in type.

[0044] Furthermore, in the intermediate layer, the application server 6 is a computer which accommodates the client terminals 1₁-1₃via the network 3, and is connected to the database servers 4₁-4₃. A timer (see timer 14 in FIG. 4) is installed in the application server 6.

[0045] The application server 6 processes service requests from each of the client terminals 1₁-1₃. Additionally, the server application program 7, run by the application server 6, is recorded into a memory portion of the application server 6.

[0046] The server application program 7 is a program for performing the above-mentioned services, an example of which includes accessing the databases 5₁-5₃, described later. That is, the application server 6 accesses the databases 5₁-5₃, based on a service request from the client terminals 1₁-1₃, and performs transactions such as updating and reading data, etc. Herein, data is updated by means of a two-phase commit, comprising the two phases of temporary updating and permanent updating.

[0047] In the application server 6, the database access high level application program interface (API) 8 is an interface to access the databases 5₁-5₃, comprising the distributed transaction manager 9 and the local transaction managers 10₁-10₃.

[0048] The distributed transaction manager 9 centrally controls the above-mentioned distributed transaction processing, and controls the local transaction managers 10₁-10₃in an integrated manner. The local transaction managers 10₁-10₃correspond to the databases 5₁-5₃, and individually perform transaction processing (i.e., the transaction for accessing a database) under the control of the distributed transaction manager 9. Concretely, the local transaction managers 10₁and 10₃perform data updating and the like, by means of individually accessing the databases 5₁-5₃.

[0049] The database access application program interface (API) 11 is an interface between the local transaction managers 10₁-10₃and the databases 5₁-5₃; an example of the above-mentioned includes JDBC (Java Data Base Connectivity) which is an interface for accessing a database by means of Java.

[0050] FIG. 2 is a block diagram, showing a reference model of distributed transaction processing in the database access system according to an embodiment of the present invention. FIG. 3 is a block diagram, showing interfaces in the database access system according to an embodiment of the present invention. In the FIGS. 2 and 3, items corresponding to those shown in FIG. 1 are labeled with the same reference number.

[0051] In FIG. 2, the server application program 7 possesses an interface with the distributed transaction manager 9. Further, the server application program 7 possesses interfaces with the databases 5₁-5₃(referred to as primary interfaces); and the local transaction managers 10₁-10₃possess interfaces with databases 5₁-5₃(referred to as secondary interfaces). In actuality, the above-mentioned primary interfaces and the secondary interfaces comprise a single interface(referred to as the application/resource manager interface 13 in FIG. 3). Herein, the databases 5₁-5₃are one type of the above-mentioned resource manager.

[0052] These interfaces are described with reference to FIG. 3.

[0053] In FIG. 3, the distributed transaction interface 12 is an interface between the server application program 7 and the distributed transaction manager 9. That is, the server application program 7 (i.e., the application server 6) provides a command for transaction processing (i.e., processing of updating database) to the distributed transaction manager 9 via the distributed transaction interface 12. The distributed transaction interface 12 corresponds to the database access high level application program interface 8, shown in FIG. 1.

[0054] The application/resource manager interface 13 corresponds to the database access application program interface 11, shown in FIG. 1, and possesses interfaces between the server application program 7 and the databases 5₁-5₃, and other interfaces between the local transaction managers 10₁-10₃and the corresponding databases 5₁-5₃.

[0055] In other words, the server application program 7 (i.e., the application server 6) can access the databases 5₁-5₃via the application/resource manager interface 13; on the hand, the local transaction managers 10₁-10₃can access the databases 5₁-5₃via the application/resource manager interface 13.

[0056] Additionally, an example of the application/resource manager interface 13 includes the above-mentioned JDBC.

[0057] In the following, the operations of the above-mentioned database access system according to an embodiment of the present invention are described with reference to a sequence diagram, shown in FIG. 4

[0058] In the descriptions below, an example case is given, in which the client terminal 1₁, shown in FIG. 1, requests the application server 6 for a service, with the application server 6 updating the databases 5₁and 5₂in response to the service request. Data is updated by means of a two-phase commit, comprising the two phases of temporary updating and permanent updating, as described previously.

[0059] In FIG. 1, when a service request data is inputted from the client terminal 1₁to the application server 6 via the network 3 at time t-0, the application server 6 performs the following processing by means of running the server application program 7. In the following, processing performed by the application server 6 is regarded as processing by the application program 7.

[0060] At time t-1(which is>t-0) the server application program 7 provides a command for starting transaction to the distributed transaction manager 9 via the distributed transaction interface 12 (hereinafter, referred to as “begin command”). In this manner, the distributed transaction manager 9 provides a begin command to the local transaction manager 10₁at time t-2. As a result, the local transaction manager 10₁provides a begin command to the database 5₁(i.e., the database server 4₁) via the application/resource manager interface 13.

[0061] Subsequently, at time t-3, the distributed transaction manager 9 provides a begin command to the other local transaction manager 10₂. As a result, the local transaction manager 10₂provides a begin command to the database 5₂(i.e., the database server 4₂) via the application/resource manager interface 13.

[0062] In the same manner, the distributed transaction manager 9 provides a similar begin command for starting a transaction to the local transaction manager 10₃.

[0063] When all the databases 5₁-5₃start transaction at time t-4, the distributed transaction manager 9 outputs a signal to indicate that all of the above-mentioned transactions have begun(referred to as a return signal) to the server application program 7 via the distributed transaction interface 12.

[0064] At the time t-5, the server application program 7 provides a command for temporary updating, using SQL (Structured Query Language) to the database 5₁via the application/resource manager interface 13. Accordingly, the database 5₁is temporarily updated.

[0065] Furthermore, at time t-6, the server application program 7 outputs a signal to indicate that the database 5₁is ready for permanent updating(hereinafter, referred to as a ready signal) to the distributed transaction manager 9 via the distributed transaction interface 12. As a result, the distributed transaction manager 9 recognizes that the database 5₁is ready for permanent updating(i.e., in a state of temporary updating) and subsequently outputs a signal to indicate the recognition (hereinafter, referred to as a return signal) to the server application 7 via the distributed transaction interface 12, at time t-7. When the first return signal described above is inputted, the server application 7 starts the timer 14.

[0066] At this point, in order to update two databases 5₁and 5₂among the databases 5₁-5₃, at time t-8, the server application program 7 provides a command for temporary updating, using SQL, to the database 5₂via the application/resource manager interface 13. Accordingly, the database 5₂is temporarily updated.

[0067] Subsequently, at time t-9, the server application program 7 outputs a ready signal to indicate that the database 52 is ready for permanent updating, to the transaction manager 9 via the distributed transaction interface 12. Herein, with regard to the updating operation, when the number of ready signals inputted to the distributed transaction manager 9 corresponds to the number of the databases, the database is ready for permanent updating. Accordingly, at time t-9, the database is ready for permanent updating since a ready signal has been inputted to the distributed transaction 9 twice.

[0068] Further, the transaction manager 9 recognizes that the database 5₂is ready for the permanent updating, and subsequently outputs a signal to indicate the recognition (hereinafter, referred to as a “return signal”) to the server application 7 via the distributed transaction interface 12.

[0069] In a case of updating the database 5₃, the above-mentioned operation is performed, and a ready signal is inputted to the distributed transaction manager 9 a total of three times.

[0070] At time t-11, the server application program 7 provides a command for updating the databases 5₁and 5₂permanently (hereinafter, referred to as a “commit command”)(or a command for returning the databases 5₁and 5₂to a state before temporary updating (hereinafter, referred to as a “rollback command”)) to the distributed transaction manager 9 via the distributed transaction interface 12. Subsequently, at time t-12, the transaction manager 9 provides a commit command to the first local transaction manager 10₁.

[0071] As a result, the local transaction manager 10₁outputs a signal to indicate that the transaction processing is completed (hereinafter, referred to as an “end signal”) to the database 5₁via the application/resource manager interface 13. Subsequently, at time t-14, the local transaction manager 10₁provides a commit command to the database 5₁via the application/resource manager interface 13. Accordingly, the database 5₁is permanently updated. Subsequently, at time t-15, the distributed transaction manager 9 provides a commit command to the next local transaction manager 10₂. As a result, the local transaction manager 10₂outputs an end signal to the database 5₂via the application/resource manager interface 13 at time t-16. Then, at time t-17, the local transaction manager 10₂provides a commit command to the database 5₂via the application/resource manager interface 13. Accordingly, the database 5₂is permanently updated, and temporary updating and permanent updating of all the databases to be updated, the databases 5₁and 5₂, are completed.

[0072] Subsequently, after permanent updating is completed, the distributed transaction manager 9 outputs a return signal to the server application 7 via the distributed transaction interface 12 at time t-18. Accordingly, the server application 7 recognizes that the processing for updating the databases 5₁and 5₂is completed.

[0073] In addition, the timer 14 observes the time period between the start of the operation, and an input of a return signal with respect to the last local transaction manager 10₂(referred to time t-10) i.e., the time period between starting and a state when all the databases to be updated are temporarily updated. When the above-mentioned time period exceeds the predetermined time period, the timer 14 judges the situation as a time-out. Herein, examples for causing a time-out may include mechanical troubles of the database server 4₁and the like; and cases in which temporary updating of the databases 5₁and 5₂are not completed in a normal fashion, due to a defect in the network or the like.

[0074] Herein, for example, the timer 14 determines that a time-out is required at time t-19 since temporary updating of the database 5₁is not completed in a normal manner, due to the above-mentioned reason. Accordingly, at time t-19, the timer 14 provides a rollback command for returning the databases 5₁and 5₂to a state before temporary updating, to the distributed transaction manager 9 via the distributed transaction interface 12. As a result, at time t-20, the distributed transaction manager 9 provides the above-mentioned rollback command to the local transaction manager 10₁. Thereafter, at time t-21, the local transaction manager 10₁outputs an end signal to the database 5₁via the application/resource manager interface 13. Subsequently, at time t-22, the local transaction manager 10₁provides a rollback command to the database 5₁via the application/resource manager interface 13. Accordingly, the database 5₁is returned to a state prior to temporary updating.

[0075] Subsequently, at time t-23, the distributed transaction manager 9 provides a rollback command to the next local transaction manager 10₂, in the same manner as with the above-mentioned operation. Then, at time t-25, the local transaction manager 10₂provides a rollback command to the database 5₂via the application/resource manager interface 13. Accordingly, the database 5₂is similarly returned to a state preceding the temporary updating.

[0076] When all of the processing are completed, the distributed transaction manager 9 outputs a return signal to the server application program 7 via the distributed transaction interface 12, at time t-26.

[0077] As described above, according to the database access system described in the above-mentioned embodiment of the present invention, it is possible to simplify processing control, when compared to a conventional database access system, and thus also simplify the overall system structure, by means of having the local transaction managers 10₁-10₃correspond to the databases 5₁-5₃, and individually accessing the databases 5₁-5₃.

[0078] Additionally, according to the database access system described in the above-mentioned embodiment of the present invention, it is possible to reduce the number of interfaces, compared to a conventional database access system, and thus also reduce costs, by means of accessing the databases 5₁-5₃from the server application program 7 and the local transaction managers 10₁-10₃, using a single application/resource manager interface 13, as shown in FIG. 2.

[0079] Furthermore, according to the database access system described in the above-mentioned embodiment of the present invention, it is possible to access databases even if the databases 5₁-5₂differ in type, by means of having the local transaction managers 10₁-10₃correspond to the databases 5₁-5₃.

[0080] In the above-mentioned, a database access system according to an embodiment of the present invention is described in detail; however, its concrete structure is not limited to the above-mentioned embodiment, and the present invention may also include modifications in this design as long as these modifications do not deviate from the essential components of the present invention.

[0081] For example, in the database access system according to the above-mentioned embodiment, an example is given in which the present invention is applied to a distributed database environment comprising a client layer, an intermediate layer, and a database layer (FIG. 1). However, the present invention is not limited to such environment, and can be applied to any database environment.

[0082] Additionally, it is possible to provide the database access system according to the above-mentioned embodiment, by recording a computer readable program, which causes a computer system to execute the functions of the above-mentioned database access system, on a computer usable medium; and having the computer system road and run the program recorded on the computer usable medium. Herein, the computer system may also include hardware such as OS (Operating System), peripheral devices, and the like. In addition, the computer system may also include an environment offering homepages (or a display environment), if the system utilizes a World Wide Web system.

[0083] As described above, according to the present invention, when compared to a conventional database access system, it is possible to obtain the effects of simplifying processing control, and hence also simplify the overall system structure and reduce costs, by means of providing a plurality of local transaction managers which correspond to a plurality of databases, and having these local transaction managers process, individually, accessing (i.e., updating) of the databases.

[0084] In addition, according to the present invention, it is possible to obtain the effects of accessing different types of databases, by means of providing a plurality of local transaction managers which correspond to a plurality of databases.