KR100309787B1 - Method for identifying discreted deadlock conditions on the multiple database system - Google Patents

Abstract

1. TECHNICAL FIELD OF THE INVENTION

The present invention relates to a distributed deadlock identification method in a multiple database system.

2. The technical problem to be solved by the invention

The present invention seeks to provide a distributed deadlock identification method that identifies all deadlocks that may occur while ensuring maximum system performance.

3. Summary of the Solution of the Invention

In the distributed deadlock identification method applied to a multi-database system, a first step of checking whether a timed out transaction exists and initializing an index value I of a local database and setting a read-only variable to true ; A second step of checking whether the number of the local databases is equal to or larger than the index value of the local database, initializing the access index value J of each local database, and initializing the number of accesses to the I-th local database; If the number of accesses of the I-th local database is greater than or equal to 'J', the number of accesses to the I-th local database is increased by a predetermined first number, 'J' is increased by a predetermined first number, and the number of accesses of the I-th database is increased. A third step of setting the flag to true; If the number of accesses of the I local database is not greater than 'J', check whether the flag of the 'I' local database is true, and if the flag is true, initialize 'J', specify a read-only variable, and set the flag to true. Otherwise, determining whether all accessed transactions are in read mode; A fifth step of extending a time for waiting for a response from a local database if all transactions accessed in the fourth step are in a read mode; And a sixth step of retracting the timed out transaction by checking a flag of the local database and the number of accesses to the local database if all the transactions accessed in the fourth step are not in the read mode.

4. Important uses of the invention

The present invention is used in multiple database systems.

Description

Method for identifying discrete deadlock conditions on the multiple database system

The present invention relates to a distributed deadlock identification method in a multiple database system.

Distributed deadlock identification in multiple database systems can be divided into two types. Create a time-out method that considers deadlocks and a potential conflict graph when there is no response from the system after a certain amount of time. A latent wait graph that considers deadlocks when a cycle is identified. There is a way.

While the timeout scheme as described above has a simple advantage, there is a high frequency of finding false deadlocks which, despite being not deadlocks, are regarded as deadlocks and withdraw a problem-free transaction.

On the other hand, the latent wait graph method has the advantage of identifying deadlocks more accurately than the timeout method, but the system has to stop all the work periodically and create a latent wait graph to detect deadlocks. there was.

Here, a false deadlock is called a false deadlock when the system recognizes a non-deadlock situation as a deadlock and withdraws a related transaction.

Thus, in the related art, unnecessary transaction withdrawal due to a false deadlock is brought, thereby degrading the reliability and efficiency of the system.

Therefore, the present invention devised to solve the above problems, the distribution to identify all the deadlocks that can occur while ensuring the performance of the system to the maximum by combining the timeout method and the latent wait graph method in a multiple database system Its purpose is to provide a method for identifying deadlocks.

1 is an exemplary configuration diagram of a multiple database system to which the present invention is applied.

2 is an explanatory diagram of a distributed deadlock state in a multiple database system.

3 is an explanatory diagram of a latent atmospheric graph in a distributed deadlock state;

4A to 4C are explanatory diagrams of a deadlock state, a regional database reference latent atmospheric graph, and a table reference latent atmospheric graph;

5 is an explanatory diagram for access record for each local database using a data structure.

6A and 6B are flow diagrams of one embodiment of a distributed deadlock identification method in a multiple database system in accordance with the present invention.

* Explanation of symbols for the main parts of the drawings

101: global database system 102: multiple database system

103: local database system

In order to achieve the above object, the present invention provides a distributed deadlock identification method applied to a multi-database system, by checking whether a timed out transaction exists and initializing an index value (I) of a local database and setting a read-only variable to true. A first step of setting to; A second step of checking whether the number of the local databases is equal to or larger than the index value of the local database, initializing the access index value J of each local database, and initializing the number of accesses to the I-th local database; If the number of accesses of the I-th local database is greater than or equal to 'J', the number of accesses to the I-th local database is increased by a predetermined first number, 'J' is increased by a predetermined first number, and the number of accesses of the I-th database is increased. A third step of setting the flag to true; If the number of accesses of the I local database is not greater than 'J', check whether the flag of the 'I' local database is true, and if the flag is true, initialize 'J', specify a read-only variable, and set the flag to true. Otherwise, determining whether all accessed transactions are in read mode; A fifth step of extending a time for waiting for a response from a local database if all transactions accessed in the fourth step are in a read mode; And a sixth step of retracting the timed out transaction by checking a flag of the local database and the number of accesses to the local database if all the transactions accessed in the fourth step are not in the read mode.

On the other hand, the present invention, in a multi-database system having a large processor, the first function to determine whether there is a timed out transaction, initialize the index value (I) of the local database, and set the read-only variable to true; A second function of checking whether the number of the local databases is equal to or larger than the index value of the local database, initializing the access index value J of each local database, and initializing the number of accesses to the I-th local database; If the number of accesses of the I-th local database is greater than or equal to 'J', the number of accesses to the I-th local database is increased by a predetermined first number, 'J' is increased by a predetermined first number, and the number of accesses of the I-th database is increased. A third function of setting the flag to true; If the number of accesses of the I local database is not greater than 'J', check whether the flag of the 'I' local database is true, and if the flag is true, initialize 'J', specify a read-only variable, and set the flag to true. Otherwise, a fourth function of determining whether all accessed transactions are in read mode; A fifth function of extending a time for waiting for a response from a local database if all transactions accessed in the fourth function are in a read mode; And

If all the transactions accessed in the fourth function are not in the read mode, the program is written to a computer for realizing a sixth function of retracting a timed out transaction by checking a flag of the local database and the number of accesses to the local database. It provides a recording medium that can be.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is an exemplary configuration diagram of a multiple database system to which the present invention is applied.

As shown in the figure, multiple database system 102 is a system that integrates heterogeneous database management systems with different data models and usage environments to provide a user with an environment as if using a single database system.

In addition, the multiple database system 102 may be configured in such a manner as to provide only a common protocol for accessing multiple local databases, but may have its own database system function. Regardless of whether or not it has its own built-in database system function, there are cases where multiple transactions attempt to use a limited number of database system resources simultaneously under any structure, and thus deadlocks occur. In addition, deadlocks as described above are identified in multiple database system 102 incorporating several different database systems.

2 is an explanatory diagram of a distributed deadlock in a multiple database system, and illustrates a deadlock of Table 1 below, which occurs during a transaction execution process as time passes.

time Transaction performance history T0T1T2T3T4 Global transaction 1; Write permission on global database LDB1 table T1 Owned global transaction 2; Write permission on global database LDB2 table T2 Owned global transaction 1; Write permission request for table T2 in local database LDB2 Global transaction 2; Write permission request deadlock for table T1 in local database LDB1

At the time T4 of Table 1, global transaction 1 is waiting for global transaction 2 to finish to modify table T2 in local database LDB2, and global transaction 2 is global transaction 1 to modify table T1 in local database LDB1. You are waiting for this to complete, so you are stuck in a deadlock that cannot satisfy any request.

In this case, each local database system cannot know each other's internal information and thus cannot solve the deadlock. In other words, the only information available from local database LDB1 is the fact that transaction 1 has write permission on table T1, and that transaction 2 is waiting for transaction 1 to finish writing to gain write permission, so the LDB1 database system is deadlocked. It is not recognized as a state. This deadlock occurs across multiple databases as a distributed deadlock, and the global database system must detect and terminate it.

On the other hand, deadlocks that occur within each local database are resolved by the local database system. For example, in the situation shown in Table 2 below, the local database LDB1 server resolves a deadlock.

time Transaction performance history T0T1T2T3T4T5 Global transaction 1; Write permission on global database LDB1 table T11 Owned global transaction 2; Write permission on global database LDB1 table T12 Owned global transaction 1; Write permission on global database LDB2 table T21 Owned global transaction 1; Write permission request for table T12 in local database LDB1 Global transaction 2; Request write permission on table T11 in local database LDB1 A deadlock occurred inside the local database

Deadlocks that occur internally in the regional database as described above are addressed by the regional database system.

On the other hand, distributed deadlocks that occur across multiple local database systems are resolved by the global database system. Since the deadlock that occurs in the situation as shown in Figure 2 is a distributed deadlock, each local database system cannot identify it and must be identified and resolved by multiple database systems.

In addition, distributed deadlock identification is performed independently of local deadlock identification of multiple database systems. The distributed deadlock identification method of the present invention can minimize the impact on local transactions of multiple database systems. In other words, a multi-database system may include a global database system, which is itself a single database system, or perform heterogeneous database management only by supporting global (distributed) transactions without a global database system.

The distributed deadlock identification method in the multi-database system of the present invention uses an independent deadlock identification method, so it can be used under both system configurations.

The distributed deadlock identification method in the multi-database system of the present invention has a feature that combines the advantages of the timeout method and the latent wait graph method. In other words, if a global transaction waiting for access to the local database and obtaining the result continues to wait for a response from the local database even after exceeding the specified time, the potential wait graph is generated by examining the status of the global transactions. Create a latent wait graph to consider deadlocks and retire deadlocks by relinquishing timed-awaited global transactions, and extend the wait time of waiting transactions if they are not found. Let it be.

Existing methods for identifying the existence of a loop generating a latent atmospheric graph satisfy the accuracy of the ring identification, but have a large disadvantage in that the system spends a lot of time searching for the loop and consequently degrades the performance of the system. In order to overcome this disadvantage, the present invention provides a simple ring discovery technique for identifying deadlocks. This technique has the potential to detect false deadlocks, but it can identify all deadlocks that occur and is much shorter in duration than conventional methods.

If a distributed deadlock occurs, multiple database systems withdraw the transaction waiting for a response from the local database over time to resolve it.

The unit of latent atmospheric graphing is the local database. The only information a multi-database system can have is whether or not a global transaction requested and accessed a local database. In other words. Since each local database is not known to the outside (multiple database systems) like a black box, multiple database systems can see the status of local transactions that are active inside each local database. Thus, when building a latent wait graph, the type of resource the transaction is waiting on is the local database.

FIG. 3 is an explanatory diagram of a latent atmospheric graph of a distributed deadlock state, in which the distributed deadlock state of FIG. 2 is represented by a latent atmospheric graph.

4A to 4C are explanatory diagrams of a distributed deadlock state, a regional database reference latent atmospheric graph, and a table reference latent atmospheric graph, FIG. 4A illustrates a distributed deadlock state, and FIG. 4B illustrates a regional database reference latent atmospheric graph, and FIG. 4c represents a table-based latent atmospheric graph.

As shown in the figure, in the case where the generation unit of the latent atmospheric graph is a table of each local database, the global system does not find a distributed deadlock.

In addition, if you create a latent atmospheric graph in the local database (LDB), the following loops are found.

Tran 1: Has write permission on LDB 2

Tran 2: Has write permission on LDB 1

Tran 1: Request write permission for LDB 1 (Tran 1 requires Tran 2 for LDB1)

Tran 2: Ask write permission for LDB 2 (Tran 2 asks Tran 1 for LDB2)

On the other hand, if the current situation is written in the local table unit, the loop is not found as follows. This is because the multiple database system has no knowledge of the state of transaction Tran 1-1 in LDB 1.

Tran1: possesses write permission on table T3

Tran2: possesses write permission on table T2

Tran1: Request write permission on table T1 (Tran 1 asks table T1 for?)

Tran2: Require write permission on table T3 (Tran 2 requires table T3 from Tran 1)

Therefore, in order to identify the deadlocks in all cases occurring as described above, the latent atmospheric graph must be prepared in the unit of local database. In other words, the internals of each local database behave like a blackbox that is not known to the global multidatabase system at all, so the global multidatabase system cannot obtain any information about the local transaction Tran1-1 that exists inside the local database LDB1 in FIG. none.

Thus, the global system is all the information that the global system knows that the global transaction Tran 1 has sent a write request to table T1 in the local database LDB1 but no response has been waiting. The actual situation is apparent distributed deadlock because local transaction Tran1-1 has write permission on table T1 and is requesting write permission on table T2, and global transaction Tran 2 already has write permission on table T2. By setting the target of the table as a table, the presence of local transaction Tran1-1 can't be detected, resulting in a fatal result because the loop does not appear on the latent wait graph and the actual deadlock cannot be detected. Thus, the discovery of global deadlocks requires that the target of the resource be a local database to identify all deadlocks that occur.

5 is an explanatory diagram for access record for each local database using a data structure.

As shown in the figure, a multiple database system keeps track of the time each time a global transaction makes a read / write request to the local database. If a global transaction does not receive a response from the local database for longer than the time value specified in the above environment variable, the transaction is defined as a timed transaction, from which all information about each global transaction is collected to create a latent wait graph. .

In the data structures needed to identify distributed deadlocks, access (ACCESS) is an access record that is generated each time a specific transaction accesses the local database, type is read or write, and timeout is the last request. Is the time spent, and TRAN_ID is the global transaction identifier.

The global system maintains individual access records for each regional database as follows using the data described above.

TYPE ACCESS = {TYPE, TIMEOUT, TRAN_ID}

TYPE LDB_ACCESS = ARRAY OF ACCESSES

TYPE LDB = ARRAY OF LDBs

If a global transaction in the system finds a transaction waiting for a response from the local database for more than a predefined time, a latent wait graph is created to check for global deadlocks.

The global system uses an array called cycles with as many elements as there are local databases connected to the global system to detect distributed deadlocks. Each element of the cycle consists of two fields: a flag field with a value of '1' and a local database if there are any pending transactions that exceed the response time among global transactions that access the local database. It consists of a count field that indicates the number of global transactions that have accessed, including those currently being accessed and transactions that have already returned results.

It also creates a cycle array based on the information stored in the data structure. The following example shows how to create a ring array.

tran 1: accessing LDB0 in read mode

tran 1: accessing LDB2 in read mode

tran 2: access write mode to LDB1

tran 2: access write mode to LDB3

tran 1: access write mode to LDB1

tran 2: access write mode to LDB0

In addition, assuming that tran 1 has timed out at the time of generating the latent atmospheric graph, the ring arrangement generated for global deadlock detection is as follows.

cycle [0] .flag = 1 cycle [0] .count = 2 (LDB0)

cycle [1] .flag = 1 cycle [1] .count = 2 (LDB1)

cycle [2] .flag = 1 cycle [2] .count = 1 (LDB2)

cycle [3] .flag = 0 cycle [3] .count = 1 (LDB3)

At this time, if a flag value is '1' and two or more elements in the ring array with a count value of '2' or more are found, there is a possibility that there are rings in the latent atmospheric graph. If all transactions in the found ring have accessed the local database in read mode, they are considered not deadlocked. However, if at least one transaction has accessed the local database in write mode, it is potentially deadlocked and resolves the deadlock by retracting the waiting transaction over time. In the example as described above, two of the elements of the entire ring array (cycle [0] and cycle [1]) contain the transaction tran1 which has timed out, and the count is 2 or more, so it is considered deadlock. In other words, tran1 and tran2 form rings in the latent atmospheric graph for LDB0 and LDB1. At this point, the global system breaks the loop and resolves the deadlock by retracting the timed Tran1. In this way, the possibility of loop detection is possible, but the decision algorithm is simpler and less time-consuming than the conventional method, which improves the performance of the overall system.

The performance of the conventional ring search is O (N + E) ^{(C + 1)} , whereas the method of the present invention is O (N) (where the performance comparison is only for the ring search step after plotting the latent atmospheric graph). Where N is the number of transactions, E is the number of local databases, and C is the number of rings.

The existing algorithm has the advantage of not detecting false deadlocks, but it takes a long time to detect deadlocks, which deteriorates the performance of the whole system, and in the present invention, there is a disadvantage that a false state can be detected, but the whole system In terms of performance, it has a far superior advantage.

As described above, there is always a possibility of false deadlock identification because distributed deadlock identification is not created with accurate information. False deadlock identification occurs too frequently when using the timeout method, and the potential wait graph method decreases the number of false deadlock detections, but reduces the performance of the system significantly. The present invention can reduce the number of false deadlock detections while ensuring system performance.

6A and 6B are flowcharts of one embodiment of a distributed deadlock identification method according to the present invention.

As shown in the figure, it is determined whether there is a timed out transaction in a multiple database system (601) and the local database index value I is set to '1' and the read-only variable is set to '1' (602). ).

Thereafter, it is determined whether the number of local databases is equal to or greater than 'I' (603). If the number of local databases is equal to or greater than 'I', the access index value J of each local database is set to '1', and the 'I'-th local database is determined. Is set to '0', the number of accesses to the 'I' local database is set to '0' (604), and if the number of local databases is not greater than or equal to the variable 'I', the read-only variable is '1'. Starting from the process of determining (617).

Then, it is determined whether the number of accesses to the 'I' local database is 'J' or more (605). If the number is 'J' or more, the number of transactions accessing the 'I' local database is increased to '1' (606). In operation 607, it is determined whether the timed out transaction identifier is the 'J'-th transaction identifier that accesses the' I 'local database. '1' to increase (608), and repeat the process of determining whether the number of accesses to the 'I'-th local database is' J 'or more (605), and' J 'to the' I'-th local database If it is a transaction identifier accessed by, increase 'J' to '1', set the flag of the transaction that accessed 'I' local database to '1' (609), and set the number of accesses to 'I' local database. The process of determining whether it is greater than or equal to 'J' is repeatedly performed (605).

On the other hand, it is determined whether the number of accesses to the 'I'-th local database is greater than or equal to' J '(605), and if it is not' J 'or more, it is determined whether the flag of the' I'-th regional database is '1' (610) If the flag of the I'-th local database is' 1 ',' J 'is set to' 1 '(611), and it is determined whether the number of accesses to the' I'-th local database is' J 'or more (612). If not, increase 'I' by '1' (613), and repeat the process of determining whether the number of local databases is greater than or equal to the variable 'I' (603).

On the other hand, it is determined whether the number of accesses to the 'I'-th local database is greater than or equal to' J '(612). 614) If the type is not write, increase 'J' by '1' (615), and repeat the process of determining whether the number of accesses to the 'I' local database is 'J' or more (612), and the write is In this case, the read-only variable is set to '0', 'J' is increased by '1' (616), and the process of determining whether the number of accesses to the 'I' local database is 'J' or more is repeated (612). ).

Meanwhile, it is determined whether the flag of the 'I'-th local database is' 1 '(610). If the transaction flag of the' I'-th local database is not '1', it is determined whether the read-only variable is '1' (617). If the read-only variable is '1', change the timestamp of the timed out transaction to the current time, extending the time to wait for a response from the local database (618), or deadlock if the read-only variable is not '1'. The related number of rings in K is set to '1' and 'I' is set to '1' (619).

Then, it is determined whether the number of local databases is greater than or equal to 'I' (620). If the number of local databases is greater than or equal to 'I', the flag of the transaction approaching the 'I' local database is '1' and the 'I' local database is determined. Determining if the number of accesses to '2' is greater than (621), if the flag is '1' and if the number of transactions is not '2', increasing 'I' to '1' (622) and the number of local databases is 'I' Repeat the process of determining whether it is abnormal (620), if the flag is '1', if the number of access is '2' or more, 'K' is increased by '1' (623), 'I' is increased by '1' In step 622, the process of determining whether the number of local databases is equal to or greater than 'I' is repeated (620).

On the other hand, it is determined whether the number of local databases is greater than or equal to 'I' (620). Breaking the transaction by withdrawing the transaction (625) and extending the time to wait for a response from the local database by changing the timestamp of the timed transaction to the current time if 'K' is not greater than '2' (618). ).

The method of the present invention as described above may be implemented as a program and stored in a computer-readable recording medium (CD-ROM, RAM, ROM, floppy disk, hard disk, magneto-optical disk, etc.).

The present invention described above is capable of various substitutions, modifications, and changes without departing from the spirit of the present invention for those skilled in the art to which the present invention pertains, and the above-described embodiments and accompanying It is not limited to the drawing.

As described above, the present invention has lowered the frequency of false deadlock detection and can identify all possible distributed deadlocks and can be implemented as an independent module. , Distributed transaction monitors, multiple database systems, etc. The distributed deadlock identification and resolution module operates independently of the internal deadlock identification module via its own wait-for-graph (WFG) approach to the global database for maintenance. It has the advantage of being easily and easily scalable, highly portable, and offering the right combination of timeout and latent atmospheric graphing to provide performance and accuracy.

Claims (5)

In the distributed deadlock identification method applied to multiple database systems, Checking whether there is a timed out transaction, initializing an index value I of a local database, and setting a read-only variable to true; The number of accesses to the local database is initialized by checking whether the number of the local databases is equal to or larger than the index value of the local database, and initializing the access index value J of each local database. Initiating a second step; If the number of accesses of the I-th local database is greater than or equal to 'J', the number of accesses to the I-th local database is increased by a predetermined first number, 'J' is increased by a predetermined first number, and the number of accesses of the I-th database is increased. A third step of setting the flag to true; If the number of accesses of the I local database is not greater than 'J', check whether the flag of the 'I' local database is true, and if the flag is true, initialize 'J', specify a read-only variable, and set the flag to true. Otherwise, determining whether all accessed transactions are in read mode; A fifth step of extending a time for waiting for a response from a local database if all transactions accessed in the fourth step are in a read mode; And A sixth step of retracting the timed out transaction by checking a flag of the local database and the number of accesses to the local database if all transactions accessed in the fourth step are not in the read mode; Distributed deadlock identification method in a multiple database system comprising a. The method of claim 1, wherein the third step, The number of accesses to the I-th local database is increased by a predetermined first number, and the timed transaction identifier approaches the I-th local database in the J-th order (the order of access index values of each currently set local database). Determining a seventh transaction identifier; If the transaction identifier timed out in the seventh step is not the transaction identifier that accesses the I-th local database the J th time, 'J' is increased by a predetermined first number, and the number of accesses of the I-th local database is 'J' An eighth step of determining whether the error is abnormal and repeatedly performing the third or fourth step; And If the transaction identifier timed out in the seventh step is the transaction identifier that accessed the J-th local database for the first time, 'J' is increased by a predetermined first number, and the flag of the I-th local database is set to true. A ninth step of determining whether the number of accesses of the I-th local database is greater than or equal to 'J' and repeating the operation from the third step or the fourth step; Distributed deadlock identification method in a multiple database system comprising a. The method of claim 1, wherein the fourth step, A seventh step of determining whether the flag of the I-th local database is true; An eighth step of initializing 'J' if the flag is true in the seventh step and determining whether the number of accesses to the I-th local database is greater than or equal to 'J'; A ninth step of incrementing 'I' by a predetermined first number if the number of accesses is not greater than 'J' in the eighth step and repeating the operation from the second step; A tenth step of determining whether the 'J'-th access type to the' I'-th local database is a write when the number of accesses is 'J' or more in the eighth step; An eleventh step of initializing a read-only variable if the type accessed in the tenth step is a write, increasing 'J' by a predetermined first number, and repeatedly performing the determination process of the eighth step; A twelfth step of incrementing 'J' by a predetermined first number if the type approached in the tenth step is not a write, and repeatedly performing the determination process of the eighth step; And A thirteenth step of determining whether all accessed transactions are in a read mode when the flag is not true in the seventh step; Distributed deadlock identification method in a multiple database system comprising a. The method of claim 1, wherein the sixth step is A seventh step of initializing the relevant number of rings K in the deadlock state and the index value I of the local database, and determining whether the number of the local databases is equal to or greater than 'I'; An eighth step of determining whether 'K' is a predetermined second number or more when the number of the local databases is not 'I' or more in the seventh step; A ninth step of extending the time for waiting for a response from the local database if 'K' is not more than a predetermined second number in the eighth step; A tenth step of canceling the loop by withdrawing the timed out transaction if 'K' is equal to or greater than a predetermined second number in the eighth step; An eleventh step of determining whether a flag of the I th local database is true and the number of accesses to the I th local database is greater than or equal to a predetermined second number when the number of the local databases is 'I' or more in the seventh step; If the flag is true in the eleventh step and the number of accesses is greater than or equal to the predetermined second number, 'K' is increased by the predetermined first number, 'I' is increased by the predetermined first number, and the above steps are repeated. Performing a twelfth step; And If the flag is true in the eleventh step and the number of accesses is not greater than or equal to the predetermined second number, the thirteenth step of increasing 'I' by the predetermined first number and repeating the operation from the seventh step; Distributed deadlock identification method in a multiple database system comprising a. In a multiple database system with a large processor, A first function of checking whether a timed out transaction exists, initializing an index value I of a local database, and setting a read-only variable to true; A second function of checking whether the number of the local databases is equal to or larger than the index of the local database, initializing the access index value J of each local database, and initializing the number of accesses to the I-th local database; If the number of accesses of the I-th local database is greater than or equal to 'J', the number of accesses to the I-th local database is increased by a predetermined first number, 'J' is increased by a predetermined first number, and the number of accesses of the I-th database is increased. A third function of setting the flag to true; If the number of accesses of the I local database is not greater than 'J', check whether the flag of the 'I' local database is true, and if the flag is true, initialize 'J', specify a read-only variable, and set the flag to true. Otherwise, a fourth function of determining whether all accessed transactions are in read mode; A fifth function of extending a time for waiting for a response from a local database if all transactions accessed in the fourth function are in a read mode; And A sixth function for checking a flag of the local database and the number of accesses to the local database if the transaction accessed in the fourth function is not in the read mode, and withdrawing the timed out transaction; A computer-readable recording medium having recorded thereon a program for realizing this.