JPH08235038A - Resource updating decision system - Google Patents

Abstract

PURPOSE: To provide a resource updating decision system which decides the necessity for execution of the actual updating of resources in a resource management system of a data base, etc. CONSTITUTION: The updating flags are prepared at the prescribed points or an updating management table 33 and then allocated to the transactions under processing. In a transaction processing mode, a work program 21 produces an updating instruction of resources and an updating flag history management part 23 acquires the inverted value of the updating flags allocated to the transactions on the table 33 through an updating flag history file 25. Then an updating flag management part 31 gives an actual updating instruction to a resource manager 29 to carry out the actual updating of resources and then to invert the value of the updating flag of each transaction. If a fault occurs during the actual updating processing, the part 23 compares the value of the updating flag corresponding to the relevant transaction with the corresponding inverted value stored in an updating flag history management file via an updating confirmation request part 27 after the fault is recovered. If no coincidence is secured between both value, it is decided that the real updating processing is not carried out yet.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention manages resources such as a database and a memory table to process a transaction, and subsequently determines whether or not the actual updating of the resource is actually executed in the transaction processing. The present invention relates to a resource update determination method and method.

[0002]

2. Description of the Related Art In a resource management system such as a database, resources are updated every time a transaction is processed. However, if a failure such as a system failure or communication failure occurs during transaction processing, the actual updating of resources is executed. It may not be done. As is well known, transaction processing must not end in a half-finished state, but must either be completed (committed) or not processed (abort) at all. Therefore, when a failure occurs, it is checked after the failure recovery whether the actual update of the resource was executed in the transaction processing at the time of the failure occurrence. If the update is not executed, for example,
Redo the update and actually commit the transaction, or roll back to the state before the transaction processing started and abort the transaction.
Such a recovery process must be performed.

FIG. 1 shows an example of a conventional method for determining whether an actual resource update has been executed. In addition, FIG.
The case where one of the two servers (= processing devices) 1a and 1b connected by the network 3 manages the resource and the other 1a controls the update of the resource is shown, but this is merely an example. As a matter of course, even in another case (for example, the case where the resource management and the update control are processed together in one server), the essence of the conventional technique does not change.

As shown in FIG. 1, in one server 1a, a business processing program (hereinafter abbreviated as AP) 5, which is the main subject of transaction processing, requests the other server 1b to update resources during transaction processing. Update requesting unit 13 and another server 1b for recovery from a failure
And an update confirmation unit 15 for confirming whether or not the resource update has been completed. The AP 5 has a history file 7 recording the history of resource updates.

In the other server 9, the resource manager 9 manages resources such as the database 11 and records history information indicating whether or not the resource is actually updated for each record in the resource. Area is provided.

In the transaction processing, the update requesting unit 13 of the AP 5 first acquires a time stamp, writes the update record and the time stamp in the history file 7, and then instructs the resource manager 9 to update the record in the resource and the time. Ask to write a stamp. Upon receiving this request, the resource manager 9 writes history information such as a time stamp in the area corresponding to the update record in the database 11 and actually updates the update record.

When a failure such as system down occurs,
At the time of restart after the failure recovery, the update confirmation unit 1 of AP5
5 reads the update record and time stamp at the time of failure from the history file 7, reads the time stamp of the corresponding update record in the database 11 through the resource manager 9, and compares both time stamps. As a result, if the time stamps match, it is determined that the actual update has been executed, and if they do not match, it is determined that the actual update has not been executed.

[0008]

One of the problems of the above-mentioned conventional system is that the AP 5 is adapted to perform the update determination process, and therefore the configuration of the AP 5 becomes complicated. In addition, an area is provided in the database 11 for each resource record, and relatively complicated history information such as a time stamp is recorded therein, and correspondingly, a time stamp and an update record are also recorded in the history file 7. Since the data is recorded, the sizes of the management table 11 and the history file 7 are increased, and a useless file capacity is required.

Therefore, an object of the present invention is to provide a resource management system for processing a transaction and updating a resource, which is capable of determining whether or not an actual resource update is executed with a program structure as simple as possible and with a small file area. It is to provide a judgment method.

[0010]

The resource update determination method of the present invention comprises a business program for processing a transaction,
The update flag assigned to the transaction being processed, the update flag history file for recording the history of the update flag, and the initial value of the update flag are read, and the initial value is triggered when the actual update command is issued from the business program. Flag writing unit that writes the inversion value of the update flag history file to the update flag history file, an update flag management unit that inverts the update flag when the actual update of the resource is executed based on the actual update instruction, and whether or not the actual resource update is executed The update confirmation requesting unit that issues a confirmation request, and the flag that confirms whether or not the actual resource update is executed by receiving the confirmation request and comparing the value of the update flag with the inverted value in the update flag history file. And a check unit.

[0011]

According to the method of the present invention, the update flag is assigned to the transaction being processed. Therefore, the update flags may be prepared for the number of transactions processed in parallel.

In a transaction process, when a business program issues an actual resource update command, the inverted value of the initial value (= flag value at the start of the transaction) of the update flag assigned to the transaction is triggered by this. , Is recorded in the update flag history file. Further, when the actual update of the resource is executed by this actual update instruction, the value of the update flag assigned to the transaction is actually inverted. On the other hand, when a failure or the like occurs during the actual update processing and the actual update cannot be performed, the update flag is not inverted and is maintained at the initial value. Therefore, when the actual update is executed, the value of the update flag and the record of the update flag history file match, while when the actual update fails, the two do not match.

When a failure occurs, the value of the update flag and the record of the update flag history file are collated after recovery from the failure, and if they do not match, it is determined that the actual update has not been executed. It

The process of managing the update flag and the update history file and issuing the confirmation request can be provided as a processing unit separate from the business application. As a result, the business application can be released from the update determination process and have a simple configuration. Further, since the configuration of the update flag and the update history file can be simplified, the file size can be reduced.

[0015]

FIG. 2 shows the system configuration of an embodiment of a resource management system to which the update determination processing method of the present invention is applied.

As shown in FIG. 2, two servers 20a and 20b are connected via a network 3. The first server 20a has a business program (AP) 21, which is the main subject of transaction processing. Also,
The second server 20b has resources (not shown) such as databases, tables, and files to be updated in transaction processing, and a resource manager 29 that manages these resources.

Hereinafter, the first server 20a having the AP 21
Is called a "main server", and the second server 20b that manages resources is called a "slave server". In fact, the two servers 20a,
Although 20b has the same configuration and can be a primary server and a secondary server, respectively, in FIG. 2, for convenience of description, in the case where the first server 20a is the primary server and the second server 20b is the secondary server, Only the processing elements that function on each server are shown.

In addition to the AP 21, the main server 20a has an update flag history management section 23 and an update flag history file 25.
And an update confirmation request unit 27. In addition, the slave server 2
In addition to the resource manager 29, 0b is a predetermined number (three in this embodiment) of update flag management units 31a, 31b,
31c and an update management table 33.

The update management table 33 of the slave server 20b is provided with the same number of update flags as the update flag management units 31a, 31b, 31c. Each of these three update flags is lock-managed (free / in use),
One of the unlocked update flags is assigned to the one that has accepted the transaction in the update flag management units 31a, 31b, 31c. FIG. 2 shows the update flag management unit 3
An example is shown in which the update flag with the update flag id "1" is assigned to 1a. Each update flag can take a binary value of "0" or "1", thereby displaying whether or not the actual update of the resource is executed.

The update flag management unit 31 of the slave server 20b
Each of a, 31b, and 31c is assigned to a separate transaction process and rewrites (inverts) the corresponding update flag when the actual update of the resource is executed in each transaction process. By having these three update flag management units 31a, 31b, 31c, the slave server 20b can execute a maximum of three transaction processes in parallel.

Update flag history management unit 2 of the main server 20a
3 roughly performs the following three processes. First, in each transaction process, the sub-server 20b is inquired about the inverted value of the update flag based on the flag control command from the AP 21. The second is a function of acquiring the inverted value of the update flag requested earlier in the update flag history file 25 in response to a commit (actual update) command issued by the AP 21 to the slave server 20b in each transaction process. . The third is a process of inquiring the content of the update flag from the slave server 20b in response to a request from the update confirmation requesting unit 27 after the failure is recovered when the failure occurs.

In the update flag history file 25, the slave server 20b is stored in the update flag history management unit 23 described above.
The inverted value of each update flag inquired is recorded.

When a failure occurs, the update confirmation requesting section 27 confirms, after the failure recovery, whether or not the actual update of the resource has been executed in the transaction processing at the time of the failure occurrence. Is to ask.

The update flag history management section 23 includes a flag request section 33, a first flag writing section 35, and a flag check section 3.
7 and a confirmation result return unit 39. Each of the update flag management units 31a, 31b, 31c has a flag inverting unit 41, a second flag writing unit and a flag reading unit 45.

FIG. 3 shows a processing flow of each unit when a transaction is normally processed in the present system having the above configuration.

When the AP 21 starts processing one transaction, the transaction id assigning section 32 assigns a unique transaction id in the system to the transaction (S0). Next, A
P21 updates the flag control command, flag history management unit 23
Is issued to (S1). In the update flag history management unit 23,
In response to the flag control command, the flag request unit 33 requests one update flag management unit, such as 31a, assigned to the transaction to read the update flag value (S2).

In the update flag management unit 31a that has received this read request, the flag reversing unit 41 causes the update management table 3
The initial value (current value) of the corresponding update flag is read from S3 (S3, S4). Here, the initial value is "0" or "1", but here it is assumed to be "0", for example. Next, the flag inversion unit 41 inverts this initial value “0” and outputs the inversion result “1” to the update flag history management unit 2
It returns to 3 (S5). In the update flag history management unit 23, the flag request unit 33 receives the inversion result “1” and holds it in the memory.

After issuing the flag control instruction, the AP 21 issues a temporary resource update instruction (including information such as designation of a record to be updated and update content of the record). Although not shown, this temporary update command is passed to the resource manager 29, and the resource manager 29 requests the resource to be updated for temporary update according to this temporary update command, and temporarily records the record specified in the resource. When the update is successful, the resource manager 29 notifies the AP 21 that the temporary update is successful.

In the stage up to this temporary update, if any failure occurs, the transaction is rolled back, so all the processing results so far are discarded and the state before the transaction processing is started. Is restored.

If the temporary update is successful, AP2
1 then issues an actual update (commit) command of the resource to the update flag history management unit 23 (S6). In the update flag history management unit 23, the first flag writing unit 35 responds to the commit command with the inversion result “1” previously held in the memory, together with the corresponding transaction id and update flag identifier id, and the update flag history file. Write to 25 (S
7).

Subsequently, the first flag writing section 35 issues a flag update request to the update flag management section 31a (S8). In the update flag management unit 31a, the second flag writing unit 43 tentatively updates the value of the corresponding update flag from the initial value “0” to the inverted value “1” in response to the flag update request (S9), Then, an actual update (commit) command is issued to the resource manager 29, and if the actual update of the record in the resource is successful based on this commit command, the update flag is actually updated to the inverted value "1" (S1).
0). The step S9 may be performed after the flag inversion unit 41 inverts the flag. If a failure such as a system down occurs in the second server 20b and the actual update of the resource fails, the resource manager 29 rolls back the temporary update of the resource from the AP 21 by its own recovery process. In addition, the provisionally updated update flag is rolled back to the original initial value “0”.

In the update flag history management unit 23, the first flag writing unit 35 issues a flag update request, and then returns the processing result indicating that the commit is completed to the AP 21 (S1).
1). This completes the transaction processing.

By this series of processes, triggered by the issuance of the transaction commit command, the update flag corresponding to the transaction in the update management table 33 records a value according to the success / failure of the actual update of the resource. On the other hand, in the update flag history file 25, the expected value that the update flag should have when the actual update with the resource is successful is recorded. Therefore, when the actual update of the resource is successful, the actual value of the update flag matches the expected value recorded in the update flag history file 25. However, when the actual update with the resource fails, the actual value of the update flag and the expected value recorded in the update flag history file 25 are different.

Although not shown in the figure, during transaction processing, the resource record to be updated is kept in the locked state in order to exclude access by other transactions, and is locked after the actual update is successful. However, if the actual update fails, the locked state is continuously maintained. In response to this, when the actual update fails, the update flag assigned to the transaction is also continuously maintained in the locked state thereafter, and is not assigned to the subsequent transaction. As a result, the difference between the actual value of the update flag caused by the failure of the actual update and the expected value of the update flag history file 25 may be due to some recovery process (redo or rollback of the actual update) for the transaction. Unless done, it will continue to be maintained thereafter. Therefore, by detecting this difference after the failure recovery, it becomes possible to find out which record has not been updated.

FIG. 4 shows the flow of processing after recovery from a failure when a failure occurs.

As shown in FIG. 4, upon recovery from the failure, the update confirmation requesting unit 27 first issues an update confirmation request to the update flag history managing unit 23. Update flag history confirmation unit 23
Then, the flag check unit 37 receives this update confirmation request, and requests the flag read units to update flag management units 31a, 31b, and 31c based on the transaction id and the update flag id read from the update flag history file 25. Is issued (S22).

In each of the update flag management units 31a, 31b, 31c that have received this flag read request, the flag reading unit 45 reads the value of the update flag from the update management table 33 (S23, S24). At this time, if the received transaction id and the transaction id read from the update management table 33 are the same, it means that the actual update was in progress at the time of failure occurrence, while if they are different, the transaction has been completed. , Of course, shows that the actual update is also completed. From this, each update flag management unit 31a, 31b, 31c recognizes whether the transaction that was actually being updated at the time of the failure was under its own responsibility, and if it is under its own responsibility (the example shown in the figure). Then, the update flag management unit 31a corresponds to this), and sends the value of the update flag read earlier to the update flag history management unit 23 (S25).

In the update flag history management unit 23, the flag check unit 37 receives the value of the update flag sent from the update flag management unit 31a, and reads the value of the corresponding update flag from the update flag history file 25 ( S2
6) Compare both values. As a result, if they match, it is confirmed that the actual update has been executed, and if they do not match, it is confirmed that the actual update has not been completed, and the confirmation result is passed to the confirmation result returning unit 39 (S27). ).

The confirmation result returning unit 39 sends the confirmation result to the update confirmation requesting unit 27 (S28), and the update confirmation requesting unit 27
Receives the confirmation result and recognizes whether the actual update has been executed or not. Although not shown, an appropriate recovery process is performed based on the recognition result.

As described above, according to the present embodiment, by using the binary update flag, the actual update / execution of the resource is executed.
I have decided to determine the unexecuted. This update flag is
It is not provided for each resource record, but for each update flag management unit 31a, 31b, 31c, that is, for each transaction to be processed in parallel. Therefore, the update management table 33 is much smaller and simpler than that of the conventional one, and the update flag history file 25 corresponding thereto is also small in size and simple, and access processing to them is also easy. become. Further, in the present embodiment, since the update flag history management unit 23 and the update confirmation request unit 27 are provided separately from the AP 21, the AP 21 does not need to manage the execution / non-execution of the resource update, and the AP 21
The program structure of 21 becomes simple.

Although one embodiment of the present invention has been described above, the present invention can be implemented in various modes other than the above embodiment. For example, the present invention can be applied to a case where closed transaction processing is performed in one processing device, and a case where a plurality of processing devices perform distributed processing by managing resources in a distributed manner.

[0042]

According to the present invention, the presence / absence of execution of actual resource update can be determined with a simple program structure and a small file size.

[Brief description of drawings]

FIG. 1 is a block diagram showing a conventional update determination processing method.

FIG. 2 is a block diagram showing a system configuration of an embodiment of a resource management system to which the update determination processing method of the present invention is applied.

FIG. 3 is a flowchart showing an operation during normal transaction processing of the embodiment.

FIG. 4 is a flowchart showing an operation at the time of failure recovery of the embodiment.

[Explanation of symbols]

 3 network 20 server 21 business program (AP) 23 update flag history management unit 25 update flag history file 27 update confirmation request unit 29 resource manager 31 update flag management unit 33 flag request unit 35 first flag writing unit 37 flag check unit 39 confirmation Result return unit 41 Flag inversion unit 43 Second flag writing unit 45 Flag reading unit

 ─────────────────────────────────────────────────── ─── Continued Front Page (72) Inventor Tadao Odanaka 3-3-3 Toyosu, Koto-ku, Tokyo NTT Data Communications Corporation

Claims (2)

[Claims] 1. A method for determining whether or not a resource has been actually updated by a transaction in a resource management system, a business program that processes the transaction, an update flag assigned to the transaction being processed, and the update flag. And an update flag history file for recording the history of the update flag, the initial value of the update flag is read, and the inverted value of the initial value is written to the update flag history file upon the issuance of the actual update command from the business program. A flag writing unit that inserts the update flag, an update flag management unit that inverts the update flag when the actual update of the resource based on the actual update instruction is executed, and an update confirmation that issues a confirmation request as to whether or not the actual update is executed. The request unit, the value of the update flag, and the update flag in response to the confirmation request By comparing the inverted value of gravel in the file, resource update determination method characterized by and a flag check unit for confirming whether to execute the real update. 2. A method of determining whether or not a resource is actually updated by processing a transaction in a resource management system, a process of assigning an update flag to a transaction processed by a business program, and a process from the business program. In response to the issuance of the update command, the process of writing the inverted value of the initial value of the update flag into the update flag history file, and the execution of the actual update of the resource based on the actual update command, Reversing, generating a confirmation request as to whether or not the resource is actually updated, and receiving the confirmation request and comparing the value of the update flag with the inverted value in the update flag history file. And a step of confirming whether or not the actual update has been performed.