Clustered application server and web system having database structure

[0001] [Technical field to which the invention belongs] The present invention relates to a method of clustering application servers, a method of configuring a cache database cluster for caching database server data, and a Web system configured using these methods. [0002] [Conventional technology] When building a system in a Web environment, ensuring scalability is an important issue from the two perspectives of ensuring performance in a large-scale configuration and improving operability that can flexibly respond to sudden fluctuations in system load. In particular, in recent years, large-scale EC sites where many users require system responses close to real-time processing and portal sites that dynamically generate pages customized for each user are being actively constructed. In these systems, the number of accesses to the database is expected to increase significantly compared to the past, and ensuring scalability is becoming an increasingly important issue. At present, as shown in Fig. 3, a three-tier structure of Web server (304, 305) -application server (307) -database server (309) is usually used in the construction of a Web system. An example of the Web system usage session from the client will be described with reference to FIG. The client computers 301 and 302 (hereinafter referred to as clients) issue a request to the Web server via the network 303. The Web server that has received the request forwards the request to the application server via the network 306. The application server executes an application that processes the request, generates a processing result, and returns the processing result to the Web server. The Web server creates a Web page in which the processing result received from the application server is embedded and returns it to the client, and one session ends. Further, if the application requires access to the database (311) in the database server, the application server accesses the database server 309 via network 308 and database 311 via database system 310 in the database server. Acquire or update the data in. As shown in the system configuration in Fig. 3, in a Web system, the Web server is often configured as a cluster system. For example, in FIG. 3, L clusters from Web server 1 (304) to Web server L (305) are used. Web server clustering is mainly performed for the purpose of ensuring scalability in response to an increase in load such as an increase in clients. The reason why clustering of Web servers is easy is that the Hypertext Transfer Protocol (hereinafter referred to as HTTP) used for communication between the client and the Web server is stateless. The fact that HTTP has no state means that the communication between the client and the web server can be a new session each time communication is performed, so that session can be assigned to any web server in the cluster. means. That is, it is possible to respond to an increase in load such as an increase in users by sequentially adding rack-mount type thin servers to enhance the system. On the other hand, the application server does not work even if the server (hardware) is simply clustered because the application has a state. The reason will be explained by giving a concrete example. Assume an environment in which the same application is executed on multiple application servers in order to distribute the load. In a Web system, processing is usually carried out by interacting with the user. For example, if you consider the process of purchasing a book on a website, (1) first search for the book, then (2) decide which book to purchase from the searches, and (3) send the purchased book to. Enter, and (4) finally make a payment with a credit card or the like. Assuming that the purchase processes (1) to (4), which are logical sessions (hereinafter referred to as logical sessions), are realized as one application, the application is in each phase of (1) to (4). It involves a web session (hereinafter referred to as a web session) using the HTTP protocol between the client and the web browser. When there is only one application server, even if there are multiple Web servers, the processing can be continued by saving the state of the logical sessions (1) to (4) in the application server. .. For example, in Japanese Patent Application Laid-Open No. 11-149449, the database server assigns a session ID when performing processing and retains the processing status, and transfers the session ID to the client for processing that requires continuation, and the client When the session ID is included in the request from, the method of continuing the process from the retained state is disclosed. In this method, the state is maintained by stopping the thread that executes the session, and the processing is continued by resuming the execution of the thread upon request. However, even when this method is used, it is difficult to change the server that continuously executes the application. This is because when each of the Web sessions (1) to (4) is assigned to a different Web server and the request is transferred from the Web server to a server different from the application server that was performing the previous processing, the previous time is reached. This is because the logical session state cannot be obtained and the logical session cannot be continued. Regarding the database server, in order to ensure data consistency, usually one database management system centrally manages all data. For this reason, it has been difficult to improve scalability by clustering as in the case of application servers. The document "Oracle 9i Application Server Database cache" discloses methods for improving the performance of application servers. In this method, the data in the database server is cached in the Web server in table units, and the cached data is used as needed to avoid access to the database server. This reduces the load on the database server and improves scalability. However, in this method, when update processing occurs, processing cannot be performed in the cache, and processing in the database server is required after all, resulting in reduced performance. In addition, since the size of a table on a database server is usually very large, there are many cases where caching in units of tables is not possible when an inexpensive cluster server normally used in a Web server is used. [0003] [Problems to be Solved by the Invention] In the construction of a large-scale Web system, it is difficult to ensure the scalability of the application server and the database server, and it has been an issue to deal with an increase in users and a rapid increase in system load. Furthermore, due to the difficulty in ensuring scalability, it is necessary to use an expensive high-multiplex SMP server for the application server and database server, which are the bottlenecks of processing, in order to ensure the performance of the Web system. It was impossible. One object of the present invention is to improve the scalability of the system and to provide a Web system whose performance can be easily ensured regardless of the required scale. A specific object of the present invention is to provide a method that enables clustering of application servers. Another specific object of the present invention is to provide a clustered cache of database servers (hereinafter referred to as a cache database cluster). Yet another specific purpose is to provide a method for constructing a Web system with high strike performance by using a cluster instead of a term-multiplexed SMP server that is effective for an application server or a database server. [0004] [Means for solving problems] Typical configurations of the present invention for achieving the above object are listed below. First, the present invention provides a mechanism for storing the logical session state of an application in a clustered cache database as needed and reading the session state from the cache database. By using this mechanism, the processing of the application can be continuously executed by the application running on a different cluster server, and the application server can be clustered. Further, in the present invention, a cache database cluster that can be updated is created on the cluster server to reduce the load on the database server. In order to ensure the consistency of the update process, a mechanism for synchronizing with the database server is provided as needed. The cache database in the cache database cluster can partially cache the table, and realizes the optimum caching according to the free space of the cache. With this mechanism, access to the database server during update processing can be reduced, and the scalability of the database server can be improved. Further, in addition to the application server clustering method and the cache database cluster configuration method, the present invention provides an automatic addition mechanism of a cache database to a cache database cluster. By using this mechanism, it is possible to easily construct a cluster system with high cost performance and high scalability. [0005] BEST MODE FOR CARRYING OUT THE INVENTION FIG. 1 shows an embodiment of a suitable Web system to which the present invention is applied. In FIG. 1, the client computer 1 (101) to the client computer K (102) are connected to the Web server 1 (104) to the Web server L (105) via the network 103. The Web server is further connected to application server 1 (107) to application server M (108) via network 109. Further, the application server is connected to the cache database cluster 110 via the network 109. A cache database cluster consists of multiple cache database servers. For example, in FIG. 1, the cache database cluster includes N cluster servers of cache database server 1 (111) to cache database server N (113). Each cache database server contains a cache database (112, 118) internally. The internal configuration of the cache database server will be described later. Further, the cache database cluster is connected to the database server 1 (114) to the database server O (120) via the network 117. The database server includes databases 116 and 120 that manage the original data inside the database server. The internal configuration of the database server will also be described later. Networks 103, 106, 109, and 117 may be local area networks (LAN) connected by Ethernet, optical fiber, or the like, or wide area networks (WAN) including the Internet, which is slower than LAN. The client computer is a personal computer such as Hitachi FLORA of Hitachi, Ltd., an arbitrary computer system such as Hitachi 9000V workstation series J6000 of Hitachi, Ltd., a mobile terminal such as Persona of Hitachi, Ltd., or an inquiry. A mobile phone with an interface is also acceptable. The Web server, application server, and cache database server can be any workstation such as Hitachi 9000V Workstation Series J6000 of Hitachi, Ltd., or a space-saving low-end server such as Hitachi 9000V A500 of Hitachi, Ltd. There is no problem. The database server may be Hitachi 9000V high-end server VT850 or midrange server N4000 manufactured by Hitachi, Ltd. The following describes (1) application server clustering method, (2) cache database cluster configuration method and usage method in the Web system configured in Fig. 1. (2) will be further described based on an example in the order of (i) a query processing method using a cache database cluster, (ii) a transaction processing method on a database server, and (iii) a cache database addition processing method. In the Web system, the user issues an inquiry to the system using a dedicated program running on the client computer or a Web browser such as Microsoft's Internet Explorer or Netscape's Netscape Communicator, and responds to the inquiry. It is normal to get the result. Therefore, strictly speaking, the issuer of the query and the acquisition destination of the final result are the users, but for the sake of simplicity in the following explanation, the issuer of the query and the acquisition destination of the final result are considered to be clients. This simplification does not affect the essence of the invention. First, the application server clustering method will be described. In a preferred embodiment of the present invention, as shown in FIG. 1, the inquiry issued by the client is received by the Web server and transferred to the application server that executes the application required for processing. As described in the conventional technology, since an application normally retains its state, even if a process is assigned to an application running on an arbitrary application server, the process cannot be continued, and it is difficult to cluster the application server in the Web system. Met. Therefore, in this embodiment, the state of the logical session is saved in one of the cache databases (112, 118) in the cache database cluster 110, and the saved state is read by the application by providing a mechanism on an arbitrary application server. Enables the continuation of processing in the application of. Hereinafter, the method of saving the state in the cache database of the application and the details of the logical session continuation processing using the saved state will be described. The process of saving the logical session state by the application running on the application server 1 (107) will be described. FIG. 14 shows a flowchart showing the processing flow. First, the application that wants to save the state determines the cache database to save the state (step 1402). As a method of determining the cache database, for example, a hash function may be applied to a session ID having a unique value in the system to determine the cache database of the storage destination. As a method of generating a session ID having a unique value in the system, for example, the unique ID of the Web server and the unique ID generated in the Web server may be concatenated. As explained in the book purchase session example, a logical session contains multiple HTTP sessions. In order to assign a unique session ID to each logical session in a clustered Web server, (1) If the request from the client does not include the session ID, the above-mentioned unique session ID is generated. When conducting an HTTP session with a client in the middle of a logical session, the value to which the session ID is assigned is returned. (2) When the session ID is included in the request from the client, the method of using the session ID may be used. After deciding where to save the state cache database, write the state of the application to the cache database (step 1403). The state writing in the cache database and the reading processing of the state are performed by the session management unit (207) in the cache database server shown in FIG. 2, and the written data is held in the session management table 222. The session management table may be retained in the cache database 112 as a database table, in the memory of the cache database server, or as a file on the cache database server. Figure 16 shows an example of the session management table. The information to be retained is the session ID, the application name to be continued and its continuation checkpoint, and the variable used at the time of continuation and its value set. For example, for a logical session with session ID 10021, the application name is customer_management, the checkpoint indicating the progress of the session is 15, the variables to be saved at the checkpoint are c_id and c_name, and their values are 10, respectively. Itaru Nishizawa ". After writing the state, the application returns the current session ID to the client (step 1404) and ends the logical session state save process (step 1405). Next, a method for continuing the application by utilizing the logical session state stored in the cache database will be described using the flowchart of FIG. When the application server receives the request from the Web server, it checks whether or not the request includes the session ID. If the session ID is included, the cache database is specified in the same way as when the logical session state was written from the session ID (step 1508), and the logical session state in the cache database is searched (step 1502). .. If the state of the logical session was not saved in the cache database (No was selected in step 1503), the continuation process is aborted (step 1508). If the state of the logical session has been saved (Yes was selected in step 1503), read the state of the logical session from the cache database (step 1504). For example, if 10021 is specified as the session ID, the application customer_management is stopped at checkpoint 15 by searching the session management table in FIG. 16, and the variables and their values at the checkpoint are c_id = 10, c_name = It turns out that it is "Itaru Nishizawa". After reading the state, the logical session state is deleted from the cache database (step 1505). Then, the application session (logical session) is continued using the read state (step 1506). The method of saving the state in the cache database and continuing the processing of the application using the saved data reading mechanism has been described above. The method enables clustering of application servers and improves the scalability of application servers. Next, a method of configuring a cache database cluster to improve the scalability of the database server and a method of using the cache database cluster will be described. First, a query processing method using a cache database cluster will be described. As mentioned above, each cache database in the cache database cluster improves the scalability of the entire system by caching data when the application accesses the database server and reducing the access to the database server. In the Web system configured in Figure 1, the application server accesses the cache database cluster 110 to retrieve the desired data. As a method for determining which cache database in the cache database cluster the application accesses, a combination of the data used by the application and the cache database for storing the data is described, for example, as shown in FIG. You can keep the application-cache database mapping table in the application server (121, 122) and refer to that table. For example, by referring to the table in FIG. 17, it can be seen that in order to refer to the data of c_id = 100 in the table c_address referred to by the application customer_management, it is sufficient to refer to the cache database 1 of the cache database server. In the cache database cluster of the present invention, the data itself stored in each cache database is updated frequently, but the range of data to be cached is not changed frequently. Therefore, the update of the table may be executed at the time of the cache database reorganization process described later. The query processing step in the cache database server after determining the cache database to be accessed will be described with reference to the flowcharts of FIGS. 2 and 4. However, in the following example, it is assumed that the application selects cache database 1 as the cache database to be accessed. The query transferred from the application server is sent to the cache availability determination unit (203) via the network interface unit 202 of the cache database server 1 (111). The cache availability determination unit checks whether or not desired data exists in the cache database by using the stored data management table 223. A specific example of the stored data management table is shown in FIG. The stored data management table 223 stores information about the cache data managed by the cache database 1. The database server name (502) and database name (503) divide the database server name to be cached and the database name in the database server, and the table name and attribute name (504) divide the table name and attribute name to be cached. The key (505) is the division key when the table is divided and stored between the cache database clusters, the cache target data condition (506) is the condition of the data to be cached, and the cached data condition (507) is the cache target. The range of data that meets the data conditions and is actually cached in cache database 1, the refresh policy (508) is the replacement policy when refreshing the cached data, and the updateability (509) is cache database 1. The above shows whether or not the cache data can be updated. For example, in the first row record of the stored data management table 203, the cache target of caching database 1 is c_id, c_name, c_addres of the c_address table in the Customer database of database server 1. Records that consist of four attributes, s and c_phone, and satisfy the condition of 1 <= c_id <100000, and currently, records that satisfy the condition of 1 <= c_id <50000 among the caching targets are actually cached. It shows that the policy for refreshing the caching data is LRU, and that the data can be updated on the cache database 1. In the stored data management table, the cached data condition is indicated by the condition for specifying the range, but it is also possible to realize by using a bitmap representing the stored data. Going back to Figure 4, if there is data in the cache database (Yes is selected in step 402), the query issued by the application to the database server now refers to the data in the cache database. Convert (step 403). Whether or not a given query can be processed with the data existing in the cache database can be determined by comparing the query with the cached data condition. As a method for judgment, for example, Jeffrey D. Ullman, "PRINCIPLES OFDATABASE AND KNOWLEDGE-BASE SYSTEMS", VOLUME II, COMPUTER SCIENCE PRESS, ISBN 0-7167-8162-X, Chapter 14 "Optimization for Conjunctive Queries" By using the methods called Query Equivalence and Query Containment disclosed in (Reference 4), it is possible to investigate the equivalence relations and inclusion relations between conditions. Using this method, the relationship between the cached data condition and the query condition can be determined, and if the cached data condition includes or is equal to the query condition, it can be determined that the query can be processed using the data in the cache. .. When the query includes only reference processing (No is selected in step 404), the result is acquired from the cache database and returned to the application (step 405), and the query processing is terminated (step 406). The query conversion process is performed by the query conversion unit 204 in FIG. 2, and the query issuance to the cache database and result acquisition are performed by the data search / update unit 206 of the query issued by the query issuing unit 205 and the cached data 210 in the cache database 112. Execute by searching and getting the value. When the query involves any process of updating data, deleting data, or adding data to the database (corresponding to UPDATE, INSERT, DELETE in the database standard query language SQL) (when Yes is selected in step 404). Executes the cache database update process (step 407), returns the status of the update process result to the application (step 408), and ends the query process on the cache database server (step 406). The cache database update process will be described with reference to the flowchart of FIG. As described above, the database update process assumed in the present invention is either data update, data deletion, or data addition. If the update process is a data update (Yes in step 702, No in step 703), check if the update data size is equal to or smaller than the original data size before the update (step 704). .. If the update data size is equal to or less than the original data size (if Yes is selected in step 704, the updated value can be stored in the cache database, so the updated content is in the cache database log (but not). Record in (step 713), update the data in the cache database (step 714), and have an entry for the cached data condition (507) in the stored data management table in Figure 5 (step 713). If so, the value is updated (step 708), and the cache database update process is terminated (step 709). The cache database log 211 recording the update contents is held in the cache database 112 of FIG. It manages all the update history for the cache database. The cache database log management mechanism can be realized by using a general-purpose DBMS product such as HiRDB of Hitachi, Ltd., for example. Returning to step 704 in FIG. 7, if the update data size is larger than the original data size before the update (No is selected in step 704), the cache slot allocation process is executed (step 705), and the update contents are executed. In the cache database log (step 706), update the data in the cache database (step 707), and if there is an entry for the cached data condition (507 in FIG. 5) in the stored data management table. Update the value (step 708) and end the cache database update process (step 709). The cache slot securing process will be described later. If the update process is data deletion (Yes is selected in both steps 702 and 703), the update is recorded in the cache database log (step 711) and the relevant data is deleted from the cache database (step 712). ), If there is an entry for the cached data condition (507 in FIG. 5) of the stored data management table, the value is updated (step 708), and the cache database update process is terminated (step 709). Finally, if the update process is data addition (No is selected in step 702), it checks if there is space for the addition (step 710). If there is space for addition (if Yes is selected in step 710), the updates are recorded in the cache database log (step 716) and the data is added to the cache database (step 717). If there is an entry for the cached data condition (507) in the stored data management table, the value is updated (step 708), and the cache database update process is terminated (step 709). If there is no area for addition (No is selected in step 710), the cache slot allocation process is executed (step 715), the update contents are recorded in the cache database log (716), and the cache is cached. Add data to the database (step 717), update the cached data condition (507) entry in the stored data management table if it exists (step 708), and finish the cache database update process. (Step 709). The cache slot securing process will be described with reference to the flowchart of FIG. The cache slot allocation process is a process for creating a free area for caching the data when the cache database lacks an area for caching new data. First, the size of the area required to cache new data is calculated, and among the data currently in the cache, the data to be deleted from the cache (hereinafter referred to as write-back target data) is determined (step 802). The determination is made by the cache management unit 208 using the stored data management table 223 of FIG. A method of determining the data to be written back will be described using a specific example of the stored data management table shown in FIG. There is an entry for refresh policy (507) in the stored data management table. The determination of the data to be written back is executed according to the policy of the entry. For example, when it is desired to delete one record from the cached data of the table c_address, since the refresh policy of the table is LRU, the data in the cache with the oldest referenced date and time is selected as the deletion target. After determining the data to be written back, it is checked whether or not an entry related to the data to be written back exists in the cache database log (step 803). The presence of an entry in the cache database log indicates that the write-back data has been updated on the cache, and when deleting the write-back data from the cache database, the change is made. It needs to be reflected in the database server. Therefore, if an entry exists in the cache database log (Yes is selected in step 803), the write-back data and the cache database log for that data are committed to the database server (step 804). In order to reduce the cost of determining whether or not the data to be written back has changed by analyzing the cache database log, prepare a bitmap that determines whether or not the record has been updated, and only when the update is confirmed by checking the bitmap. A realization example of analyzing cache database logs can be considered. Returning to FIG. 8, if the commit is successful (Yes is selected in step 805), the data to be written back is deleted from the cache database (step 806), and the cache slot allocation process is terminated (step 807). ). If the commit to the database server fails (No is selected in step 805), select other data to write back and choose whether to retry (step 808). When retrying (when Yes is selected in step 808), the process returns to step 802 and the above process is repeated. If no retry is performed (No is selected in step 808), the cache slot allocation process is aborted (step 809). Returning to step 402 of query processing on the cache database server in FIG. 4, if there is no data in the cache database (No is selected in step 402), the query is converted for the database server (step). 413), transfer (step 409), get the result for the query (step 410), and return the obtained value to the application (step 411). The query conversion and transfer processing are executed by the query conversion unit 204, the query issuing unit 205, and the network interface unit 202 of FIG. 2, respectively. A specific example of the query conversion for the server in step 413 will be described using the stored data management table of FIG. Consider the case where the application issues the query shown in 1801 in Fig. 18 to the cache database 1. The inquiry corresponds to seeking the name (c_name) of a customer whose customer ID (c_id) is 60000. As shown in the cached data condition (507) of the record in the first row of FIG. 5, the customer name is not in the cache database and needs to be transferred to the database server. The database server 114 receives the inquiry transferred from the cache database server in the network interface unit, the data management / inspection unit 218 searches the database 118, and records from the stored original data 221 that satisfy the inquiry conditions. Extract and return to the cache database server. However, if query 1801 is transferred to the database server as it is and the result is acquired, the acquired result will include only c_name, and the entry of "table name and attribute name" indicating the cached table and attribute name in Fig. 5. It does not include the values of the other three attributes (c_id, c_address, c_phone) required as the entry of (504), and caching is impossible as it is. Therefore, query 1801 is converted to include other attributes required for caching, as shown in 1802, before being transferred to the database server. The query process executes the cache database refresh process (step 412) using the record acquired by the converted query, and ends (step 406). The refresh process is a process of reflecting the record acquired as a result of the query process in the cache database as needed. The cache database refresh process will be described with reference to the flowchart of FIG. First, it is checked whether or not there is free space in the cache database for storing the data newly acquired from the database server (step 602). If there is free space (Yes is selected in step 602), the data is cached in the free space (step 606), and the cache database refresh process is terminated (step 607). If there is no free space in the cache database (No is selected in step 602), the data newly acquired from the database server and the data existing in the cache are replaced according to the refresh policy. A pass / fail judgment is made (step 603). The refresh policy is an item that specifies a cache replacement policy, as shown in 508 of the stored data management table in FIG. 5, and (1) LRU that replaces the data with the oldest date and time used, ( 2) Frequency of use to replace infrequently used data in cache, (3) Priority specification to give user-specified priority to cached data to determine replacement target, and (4) Write back of database server An example is write-back reduction that replaces unnecessary data. When the cache data is replaced with the data acquired from the database server as a result of determining whether or not the replacement is possible according to the refresh policy (when Yes is selected in step 604), the cache slot allocation process (step 605) is executed. , Cache the data in free space (step 606), cache database refresh End the process (step 607). If it is determined that the cache data will not be replaced with the data acquired from the database server as a result of determining whether to replace it according to the refresh policy (when No is selected in step 604), the cache is cached without replacing the cache. End the database refresh process (step 607). This is the end of the explanation of the query processing method using the cache database cluster. In this implementation example, it was determined whether or not to process the query with the cached data based on the cached data condition (507) in FIG. However, depending on the type of application, the cache target data condition (506) is used instead of the cached data condition (507) to make a judgment, and if the value cannot be obtained by actually searching the cache database, the value cannot be obtained again. An embodiment in which a query is issued to the database server is also possible. The present embodiment has an advantage that the maintenance cost of the cached data condition can be reduced. Next, the transaction processing method on the database server side will be described using the flowchart of FIG. The transaction processing is executed by the transaction management unit 217 of the database server 114 shown in FIG. 2 using the information in the cache database management table 219 held by the cache database management unit 216 of the figure. A specific example of the cache database management table is shown in FIG. The cache database management table 219 contains the cache database server name (1002), the database name in the database server (1003), the table name and attribute name (1004), the partition key (1005), the cache target data condition (1006), and the cached data condition. Includes (1007), updateability (1008), and operating status (1009). The meaning will be explained using the record in the first row of the table. The record caches the attributes c_id, c_name, c_address, c_phone of the record that satisfies the condition that the c_id of the table c_address included in the database Customer in the database server is 1 <= c_id <100000 in the cache database 1 in the cache database server 1. What to do, and in fact the above records that currently satisfy 1 <= c_id <50000 are cached, It indicates that the cache database is up and running and can be updated in the cache. Regarding the cached data condition, even if the range is specified as shown by the records # 1 and # 2 in FIG. 10, or the bitmap that holds the ID of the cached record is specified as shown in # 3. You may. Further, regarding the cached data condition, it is possible to leave the cached record as empty (NULL) without recording the cached record on the database server side. In this case, in the present invention, the determination process relating to the cached data condition is replaced with the cached data condition. As a result, the database server side recognizes that there is more data on the cache database side than the data actually cached on the cache database side, and transaction processing can be executed less often, but the cache database side. There is an advantage that it is not necessary to update the cache database management table every time the cache is updated. Returning to FIG. 9, from the cache database management table, the range of data referenced in the transaction overlaps with the "cached data condition" of the table (if the entry is NULL, the "cached data condition" is used). Extract a record (step 902). For example, suppose the cache management table is as shown in FIG. 10, and the transaction of the database server is "change the telephone number of the customer whose customer ID is 10." At this time, the transaction refers to and updates the record of c_id = 10 in the c_address table. In this case, the cache database server that overlaps with the transaction is the cache database server 1. Next, in step 903, the records extracted as a result of step 902 are checked. If there are no extracted records (Yes is selected in step 903), then transaction processing is performed because there is no cache in any cache database for the table to be referenced or updated in the server transaction (if Yes is selected in step 903). Step 906), exit (step 907). If there are records extracted as a result of step 902 (No is selected in step 903), whether the transaction contains only reference processing (step 904) and at least one Yes in the updatable column of the extracted records. Check if exists (step 905). If the transaction includes only reference processing and all the updateability fields of the extracted records are No (Yes in step 904, No is selected in step 905), the data referenced by the transaction is also updated on the cache database side. The transaction is executed (step 906) and the process is terminated (step 907) because it is guaranteed that the transaction has not been performed. If the transaction involves an update process, or if the extract record's updateability field contains Yes (No is selected in step 904, or Yes is selected in both steps 904 and 905). In order to avoid the inconsistency that the data cached on the cache database is updated on the database server, or the update on the cache database server is ignored on the database server. If the synchronization / blocking process of the pre-cache database included in the "cache database name" of the extracted record is executed (step 908) and the synchronization / blocking process is successful (Yes is selected in step 909), Execute the transaction (step 906) and end the process (step 907). If the synchronization / blocking process fails (No is selected in step 909), the transaction is aborted (step 910). The synchronization / blocking process of the cache database will be described with reference to the flowchart of FIG. This section describes the synchronization / shutdown processing related to the database server j in the i-th cache database i. However, in the flowchart of FIG. 11, the sentence "related to database j" is omitted due to space limitations. First, the cache database i stops accepting transactions that access the cache data in the database server j (hereinafter referred to as transactions related to the database server j) (step 1102). After all transactions related to database server j are completed (if Yes is selected in step 1103), the "database server name" in the stored data management table in the cache database is database server j and its "updatable" Check if there is at least one Yes in the field. If no Yes exists (No is selected in step 1104), the cache database i does not update the database server j, so the data in the cache database related to the database server j is deleted. (Step 1107), the synchronization / blocking process is terminated (step 1108). If there is at least one Yes in the "Updatable" entry field (Yes was selected in step 1104), the "Updating" For all tables whose entry field is Yes, the update on the cache database is reflected in the database server j. The reflection process is performed not only on the updated data image but also on the cache database log which is the update history (step 1105). If the reflection process is successful (Yes is selected in step 1106), the data related to the database server j in the cache database is deleted (step 1107), and the synchronization / shutdown process is terminated (step 1108). If the reflection process fails (No is selected in step 1106), the synchronization / blockage process is aborted (step 1109). In this embodiment, only the transaction related to the database server j is stopped, but if the transaction cannot be stopped selectively, all the transactions must be stopped in the cache database i. In this case, there is a limitation that cache data other than the database server j cannot be used temporarily, but it goes without saying that the present invention is applicable. This is the end of the explanation of the transaction processing method on the database server. Finally, the cache database addition processing method will be described. When adding a new server to the cache database cluster, as shown in Fig. 13, the server should be added to the cluster (1302) and the cache database reorganization process should be executed (1303). The cache database reorganization process will be described with reference to the flowchart of FIG. First, synchronize / block processing is executed for all cache databases (step 1206). If the synchronization / blocking process fails (No is selected in step 1202), the cache database reorganization process is aborted (step 1205). If the synchronization / shutdown process is successful (Yes is selected in step 1202), the cache database management table and application-cache database mapping table are reconfigured (step 1203 and step 1207), and the cache database is reorganized. End the process (step 1204). [0006] [Effect of the invention] By using the present invention, application servers can be clustered and a cache database cluster that can be updated can be configured, and a highly scalable Web system can be realized. Furthermore, it is possible to build a system using an inexpensive cluster server instead of a highly multiplexed SMP server, and the cost performance of the system is improved. [Simple explanation of drawings] FIG. 1 is a diagram showing a configuration of a Web system including clustering of application servers and a cache database cluster in the present invention. FIG. 2 is a diagram showing a configuration of a database server and a cache database server. FIG. 3 is a diagram showing a configuration of a standard Web system in a conventional method. FIG. 4 is a flowchart showing a query processing step in a cache database server. FIG. 5 is a diagram showing an example of a stored data management table of a cache database server. FIG. 6 is a flowchart showing a cache database refresh processing step. FIG. 7 is a flowchart showing a cache database update processing step. FIG. 8 is a flowchart showing a cache slot allocation processing step of a cache database. FIG. 9 is a flowchart showing a transaction step on a database server. FIG. 10 is a diagram showing an example of a cache database management table of a database server. FIG. 11 is a flowchart showing a cache database synchronization / blocking processing step. FIG. 12 is a flowchart showing a cache database reorganization processing step. FIG. 13 is a flowchart showing additional processing steps of a cache database. FIG. 14 is a flowchart showing a session state saving processing step of an application. FIG. 15 is a flowchart showing a session continuation processing step of an application. FIG. 16 is a diagram showing an example of a session management table of a cache database server. FIG. 17 is a diagram showing an example of an application-cache database mapping table of an application server. FIG. 18 is a diagram showing an example of query conversion for a server. [Explanation of symbols] 121,122 ... Application-Cache Database Mapping Table, 210 ... cached data, 211 ... cache database log, 219 ... cache database management table, 221 ... Original data in the database server, 222 ... session management table, 223 ... Stored data management table.