JPH10232809A - Transaction processing system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce the overheads of data access and to improve throughput by improving the form and method of data management. SOLUTION: Data used for jobs are managed by being distributed to the three kinds of resources that are a direct-read-after-write type log 6 for storing the execution history of a transaction, a counter 7 for storing the data for performing only addition and subtraction though frequently accessed and a data base 8 for storing the other data of relatively complicated constitution. In the processing of the transaction, an input message is recorded in the log 6 first, the updating processing of the data base 8 is started next and then, the updating processing of the counter 7 is started. Then, the updating processing of the counter 7 is committed, the updating processing of the data base 8 is committed and finally a transaction executed result is recorded in the log 6. The updating of the counter 7 can be canceled even after commitment. The lock period of the respective records of the counter 7 is limited only to the period of referring to and updating the respective records.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a system for transaction processing such as online banking processing and airline ticket reservation / ticketing processing.

[0002]

2. Description of the Related Art For example, a process of depositing and transferring a bank account online is a process of accessing various data related to the transaction, such as bank account information, deposit / withdrawal amount, transaction history, and updating the content thereof. Consists of Processing of these multiple data collectively constitutes a logical unit of online database processing,
This logical unit is called a “transaction”.

[0003] A transaction changes the content of a plurality of data associated therewith, but the changed content of all data must be consistent and consistent with each other. For this reason, a transaction processing system that manages all data by automatically storing all data necessary for business in a single database and automatically compensates for their consistency has been conventionally used. Widely used.

[0004] On the other hand, a transaction processing system in which a plurality of data required for business are distributed and managed in a plurality of databases has been conventionally used. In this type of system, to maintain the consistency of data distributed on multiple databases, N.I. J. Gra
The two-phase commit method and the three-phase commit method devised by Y are used.

[0005]

The conventional transaction processing system has several problems as follows.

(1) Problems of Commit Method In a system in which data is distributed and managed on a plurality of databases, a two-phase commit method is widely used as a method for maintaining the consistency of the distributed data. ing. However, in this commit method, in a commit phase of a transaction, a synchronous process involving two round-trip communication processes between a database manager and a transaction manager (that is, a commit preparation instruction and response, and a commit execution instruction and response) is performed. You have to do it. Therefore, a communication overhead having a length that cannot be ignored is generated, and the throughput is reduced.

(2) Problems in data arrangement Data used for business operations has only a complicated structure such as bank account information, and is referred to only as a table for converting a branch code into a branch name. There are various types of data, such as data of write-once type, such as transaction history, write-once data that is only written, and data that is only added or subtracted, such as the amount of money paid and withdrawn. In conventional systems,
Their data (whether distributed or not)
All are managed by a database. However, while a database can manage data having a complicated structure, the database also has a disadvantage that the data access overhead is large because of having a complicated configuration for that purpose. Therefore, the overhead is too large to store a simple code conversion table, transaction history, and the like, which also causes a decrease in throughput.

(3) Problems with the Lock Period Data such as deposits and withdrawals has a high access frequency. When such frequently accessed data is managed in the database as in the past, the database generally holds the data lock from the start of data access to the commit, so it must keep the counter lock during the transaction period. become. This can easily become a bottleneck in the system.

Accordingly, an object of the present invention is to improve the form and method of data management in a transaction processing system to reduce data access overhead and increase throughput.

[0010]

SUMMARY OF THE INVENTION The present invention provides a log for storing a transaction execution history, a counter for storing data that is only added / subtracted, and the log and counter of data used for business. The present invention provides a transaction processing system comprising: a database for storing data other than the data stored in the database; and a transaction processing means for receiving an input message requesting a transaction and processing the transaction. In this system, data used for business is managed on different resources, such as logs, counters, and databases, depending on the type.

In the transaction processing system according to the present invention, the transaction processing means preferably comprises:
(1) record an input message in the log, (2) start a database subtransaction for updating the database, and a counter subtransaction for updating the counter, (3) commit the counter subtransaction, 4) committing the database sub-transaction, (5) writing the transaction execution result to the log, (1), (2), (3), (4), (5) can be executed in this order. it can.

[0012] Also, the counter may preferably have cancellation means for canceling the updating of the counter even after the counter subtransaction has been committed.

Further, the system of the present invention can include a recovery processing means for recovering an incomplete transaction, and the recovery processing means preferably has a record of an execution history corresponding to a log. The incomplete transaction is detected based on whether the transaction has been completed. If the database subtransaction of the detected incomplete transaction has already been committed,
The execution result is recorded in a log so that the incomplete transaction is completed in a state where the transaction has been completed.On the other hand, if the database subtransaction of the detected incomplete transaction is not yet committed, the incomplete transaction is regarded as a transaction The update of the counter can be canceled and the execution result can be recorded in a log so that the execution is completed in the state.

[0014] In the system of the present invention, the transaction processing means can preferably limit the lock period of each record of the counter to only when accessing each record. The present invention is typically realized by a computer, and a computer program therefor can be installed or loaded on the computer through various media such as a disk storage, a semiconductor memory, and a communication network.

[0015]

Preferred embodiments of the present invention will be described below with reference to the accompanying drawings.

1. 1. System Configuration FIG. 1 shows a system configuration of a transaction processing system according to an embodiment of the present invention suitable for online banking processing.

The computer 1 manages data used for business and processes transactions related to the business. The computer 1 has an application program 2, a database management system 3, an OLTP (online transaction processing) package 4, an operating system A system 5 is provided. The computer 1 has a plurality of terminals 10-1, 10-2, ..., 10-n via a network 9.
Is connected. Each terminal 10-1, 10-2, ...
., 10-n receive a transaction processing request such as deposit / withdrawal or transfer from the user, send the message to the computer 1, and receive a transaction processing result message from the computer 1 and return it to the user.

In the computer 1, various data used for business are distributed and managed in three types of resources. That is, the data includes a log 6 for storing a transaction history, a counter 7 for storing data such as deposits and withdrawals, which are frequently accessed but need only be added or subtracted, and other data such as account information. The database 8 is classified and stored. The log 6 is a sequential file, the counter 7 is a table for performing only addition and subtraction, and the database 8 is a database of a relational type, a hierarchical type, a network type, or the like.

The counter 7 is provided in FIG. 10 and FIG.
It has a transaction function, that is, a function that can handle a plurality of operations atomically. Further, the counter 7 has a function of executing a cancel instruction by designating a transaction identifier, so that even a once determined transaction can be canceled at any time. The counter 7 also has a checkpoint function for speeding up the recovery process.

2. Data Required for Synchronizing Data Between Resources FIG. 2 shows an outline of a transaction processing procedure in the present system.

The transaction 11 executed by the application program 2 is logically divided into sub-transactions in resource units. That is, transaction 11
Is logically divided into a subtransaction 12 of the database 8, a subtransaction 13 of the counter 7, and a transaction management (start / completion) 14 of the log 6.

FIG. 3 shows management data for synchronizing data among the three types of resources: the database 8, the counter 7, and the log 6.

Using "transaction identifier (Tid; Transaction id)" as information for associating subtransactions between resources, synchronous processing among subtransactions 12, 13 and 14 included in the same transaction 11 is performed. . For this purpose, the following information is stored on each of the resources 8, 7, and 6 using the transaction identifier as a key.

On the database 8, a database sub-transaction execution history table 21 is provided in addition to a database which is a set of general data such as account information (that is, the database 24 in FIG. 4). The database sub-transaction execution history table 21 manages the number of the transaction 11 having the identifier which has completed the processing (database sub-transaction 12) for the database 8. That is, the “transaction identifier” of the completed transaction 11 of the database subtransaction 12 is stored in this table 21. Updates to this table 21 are made permanent in synchronization with the commit of the database subtransaction 12.

A counter subtransaction update history table 22 is provided on the counter 7 in addition to a table holding data such as deposit and withdrawal amounts (that is, the counter table 25 in FIG. 4). Counter subtransaction update history table 2
In 2, the number of the transaction 11 having the identifier which has completed the processing for the counter 7 is managed. That is, the table 22 includes the “transaction identifier” of the transaction 11 for which the processing (the counter sub-transaction 13) for the counter 7 has been completed and the “update history” of the update performed on the counter table 25 in the processing. Updates to this table 22 are made permanent in synchronization with the commit of the counter subtransaction 13.

A transaction execution history table 23 is provided on the log 6 and manages the number of the transaction 11 having an identifier which has started and completed processing. In other words, this table 23 shows that when transaction 11 starts processing, that transaction 1
The “transaction identifier” and the “input message” of No. 1 are written, and when the transaction 11 completes the processing, the “execution result” of the transaction is further written. The update to the table 23 is made permanent in synchronization with the completion of the log input / output request.

3. Transaction Processing Sequence FIG. 4 shows a transaction processing sequence performed by the computer 1.

Hereinafter, the processing sequence will be described in chronological order.

(1) Receiving an input message An input message is received from the terminal 10.

(2) Transaction Identifier Assignment Next, a transaction identifier is assigned to an input message from the terminal 10.

(3) Input message writing Next, the transaction execution history table 23 of the log 6
Write "transaction identifier" and "input message". The “transaction identifier” and the “input message” written in the table 23 are stored in a non-volatile medium such as a disk storage device by the time the input message writing process is completed.

(4) Referencing / updating of the database Next, the database 2 in the database 8 is changed if necessary.
5 and update.

(5) Inserting a database execution history Next, a transaction identifier is written in the transaction execution history table 21 in the database 8.

(6) Referencing / Updating of Counter Next, the counter is updated with reference to the counter table 25 in the counter 7 as necessary. At the same time that the counter table 25 is updated, the “transaction identifier” and the “update history” are inserted into the counter sub-transaction update history table 22. Counter subtransaction update history table 2 updated in this way
2 may be stored in the non-volatile medium by the time the commit of the counter subtransaction 13 is completed, and need not be stored in the non-volatile medium at the time of the counter reference / update processing. Further, since the operations that can be performed on the data in the counter table 25 are limited to only addition and subtraction, it is not necessary to hold the lock of the counter table 25 until the counter subtransaction 13 commits. Therefore, the lock period of each record in the counter table 25 is limited only to the period during which the record is being referenced / updated.

(7) Counter Subtransaction Commit Next, the counter 7 is declared to commit the counter subtransaction 13. By the time the commit of the counter subtransaction 13 is completed, the “update history” of the counter subtransaction 13 (that is, (6)
The "update history" written in the update history table 22 in the process (1) is stored in the non-volatile medium.

(8) Database Subtransaction Commit Next, a commit of the database subtransaction 12 is declared to the database 8. By the time the commit of the database subtransaction 12 is completed, the “execution history” of the database subtransaction 12 (that is, the “transaction identifier” written in the execution history table 21 in the process (5)) is stored in the non-volatile medium.

(9) Writing Transaction Execution Result Next, the transaction execution result (“satisfied” or “unsuccessful” of the transaction) is written in the transaction execution history table 23 of the log 6. The transaction execution result of the transaction 11 written in this manner is stored in the non-volatile medium by the time the transaction execution result writing process is completed.

(10) Transmission of Output Message Finally, an output message is transmitted to the terminal 10.

FIG. 5 shows (6) in the sequence described above.
7 shows the counter processing of (7) in detail.

In the initial state, for example, it is assumed that the amount of the branch “1” in the counter table 25 is “0”, and that the counter sub-transaction update history table 22 has no data. In this state, Tid is number “1”,
It is assumed that a transaction occurs in which the amount “100” is paid to the branch “1”. Then, the counter update processing and the counter commit processing of this transaction are performed in the following procedure.

(1) In the counter update process, first, an update lock of the record of the branch “1” in the counter table 25 is acquired.

(2) Next, in the update history table 22, the Tid
"1" and the update history "branch = 1, amount + = 100" are written.

(3) Next, “100” is added to the amount of money of the record of the branch “1” in the counter table 25.

(4) Next, the update lock of the record of the branch “1” in the counter table 25 is released. This ends the counter update processing.

(5) In the subsequent counter commit processing, the record of Tid “1” in the update history table 22 is written to a non-volatile medium such as the disk storage device 31.

4. Recovery Processing Sequence FIG. 6 shows an example of a transaction that has been completely committed (hereinafter, referred to as a completed transaction) and a transaction that has not been completely committed due to the occurrence of an abnormality during processing (hereinafter, referred to as an incomplete transaction).

Transactions T1 and T2 indicate completed transactions, of which T1 indicates that the transaction has been "established", and T2 indicates that the transaction has been rolled back during processing and the transaction has been "not established". Transaction T3
T6 show examples of some incomplete transactions at different processing stages in which an abnormality has occurred.

FIG. 7 shows a recovery processing sequence of an incomplete transaction of a transaction “established”, and FIG. 8 shows a recovery processing sequence of an incomplete transaction of a transaction “unestablished”.

Hereinafter, the recovery processing sequence shown in FIGS. 7 and 8 will be described in chronological order.

(1) Extraction of Incomplete Transactions By examining the transaction execution history table 23 of the log 6 in the non-volatile medium (disk) 31, the incomplete transactions (that is, the transaction execution results are written in the execution history table 23). (Tid not transaction).

For example, when the transaction execution history table 23 is recorded as shown in FIG. 9, the transactions of Tid = 1 and 2 are completed transactions, but the transactions of Tid = 3 to 6 are incomplete transactions. . Therefore, transactions of Tid = 3 to 6 are targets of the recovery processing.

(2) Extraction of incomplete database subtransaction Next, the transaction execution history table 21 of the database 8 in the non-volatile medium (disk) 31 is examined, and the completion / incomplete of the database subtransaction 12 for each incomplete transaction is checked. Find out. Only transactions for which the database sub-transaction 12 has been completed are defined as “transactions completed”, and those for which the database sub-transaction 12 is not completed are determined as “transactions not completed”.
By doing so, it is determined whether “transaction completed” or “transaction not completed” for each uncompleted transaction.

For example, if the database sub-transaction execution history table 21 is recorded as shown in FIG. 10, transactions with Tid = 1 to 3 are "transaction completed" because the database sub-transaction 12 has been completed. Transactions with Tid = 4 to 6 are "transaction not established" because the database subtransaction 12 is not completed.

Therefore, Tid = 3 extracted in the example of FIG.
Of the incomplete transactions No. to No. 6, Tid = 3 is determined to be “transaction completed”, and Tid = 4 to 6 is determined to be “transaction not completed”.

The subsequent processing is divided into two types depending on whether “transaction is completed” or “transaction is not established”.

(3) When a Transaction is Completed (FIG. 7) Since the processing of the database 8 has been completed for an uncompleted transaction determined to be “transaction completed”, it is considered that the transaction has been substantially completed.
"Transaction completed" is written in the transaction execution result column of the transaction execution history table 23 of the log 6. In this case, since the database sub-transaction and the counter sub-transaction have been committed, the recovery process for the database 8 and the counter 7 is unnecessary. This ends the recovery process.

(4) Unsuccessful Transaction (FIG. 8) For an uncompleted transaction determined to be “unsuccessful”, the processing of the database 8 is not completed.
Assuming that the transaction has been substantially rolled back, first, the counter 7 cancels the counter subtransaction 13 of the corresponding Tid. Next, the transaction execution result in the transaction execution history table 23 of the log 6 is deleted. Write "Transaction unsuccessful" in the field. In this case, since the database 8 remains in the state before the occurrence of the transaction, there is no need to recover the database 8. This ends the recovery process.

FIG. 11 shows (4) in the recovery process.
The details of the counter cancellation process when the transaction is not established are described below. Hereinafter, the counter cancellation processing will be described in chronological order.

Here, as an initial state, the counter table 25
In the update history table 22, Tid "1" and update history "branch = 1, amount +
= 100 ”is recorded. It is also assumed that the recovery target is a transaction with Tid = 1. The cancellation process is performed in the following procedure.

(1) First, an update history of Tid = 1 is searched from the update history table 22 of the counter 7.

(2) Next, the update lock of the record (here, the record of the branch = 1) in the counter table 25 accessed by the transaction of Tid = 1 is acquired.

(3) Next, with respect to the record of the branch = 1 in the counter table 25, the processing of canceling the update performed by the transaction of Tid = 1 (reverse operation, that is, the addition of the amount “−100”) is performed. , Return the amount to “0”.

(4) Next, "cancel" is entered in the record of Tid = 1 in the update history table 22.

(5) Next, "Cancel" is also written in the record of Tid = 1 in the update history table 22 of the counter in the disk 31.

(6) Next, the update lock on the record accessed by the transaction with Tid = 1 (the record with branch = 1) is released. Thus, the cancellation processing ends.

5. Advantages of the embodiment The advantages of the embodiment described above from the three viewpoints of the commit method, the data arrangement, and the lock period are described below.

(1) Commit Method In this embodiment, a certain restriction is imposed on the access order for a plurality of data distributed to a plurality of resources. That is, as shown in FIG. 4, first, the input telegram is recorded in the log 6, then the update processing of the counter 7 is committed, then the update processing of the database 8 is committed, and finally, the log 6 is executed. The order of recording the results is adopted. Also, a counter 7 having a transaction function
Has a cancel processing function, and this cancel processing can be performed even after commit. as a result,
Even without using the two-phase commit method, it is possible to maintain consistency of all data. The reason is as follows.

Since the execution result of the transaction is recorded in the log 6 at the end of the transaction, it is possible to know which transaction is incomplete based on the presence or absence of the execution result.

Since the input message is recorded in the log 6 at the beginning of the transaction, when performing recovery so as to complete an incomplete transaction, the recovery can be performed based on the input message recorded first.

The update of the database is committed after the update of the counter is committed, and the update of the counter can be canceled after the commit. By canceling the update of the counter, it is possible to return to a state similar to the state in which the counter has been rolled back. An incomplete transaction for which the database update processing has been completed can be brought to a completed state only by recording the execution result in the log 6 in the recovery processing.

As described above, since the two-phase commit method is not required, the synchronization method between resources can be simplified and the speed can be increased as compared with the two-phase commit method.

(2) Data Arrangement As described above, there are various types of data used in business. For example, there are tables for referencing and updating, such as a table for storing customer account balances, and branch offices. Depending on the type of data, there are various ways to handle it, such as a table that only uses references when converting codes to branch names, and a type that only performs additional writing to keep a record of transactions. It is. In the present embodiment, such various types of data are distributed and arranged in optimal resources such as a database, a counter, and a log according to the characteristics of each data. In other words, not all data is stored in the database. for that reason,
System overhead is reduced, and response time and throughput are improved.

(3) Lock period The data lock period for accessing data that requires consistency with other data and is frequently accessed but only performs addition and subtraction, such as a counter, is defined as It is limited to data access (a period during which data on the memory is referenced / updated), not from the start of access to the commit. Thereby, the concurrency in accessing these data is improved.

Note that a machine-readable computer program for carrying out the present invention may be a medium such as a disk-type storage or a semiconductor memory for fixedly storing a program, or a program such as a communication network for dynamically storing a program. From the medium, it can be supplied to the computer.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a system configuration of a transaction processing system according to an embodiment of the present invention.

FIG. 2 is an explanatory diagram showing a relationship between a transaction and a subtransaction.

FIG. 3 is an explanatory diagram showing management data for synchronizing data between resources.

FIG. 4 is an explanatory diagram of a transaction processing sequence.

FIG. 5 is an explanatory diagram of a counter processing method.

FIG. 6 is an explanatory diagram showing an example of a transaction.

FIG. 7 is an explanatory diagram of a recovery processing sequence when a transaction is established.

FIG. 8 is an explanatory diagram of a recovery processing sequence when a transaction is not established.

FIG. 9 is an explanatory diagram showing a recording example of a transaction execution history table of a log.

FIG. 10 is an explanatory diagram showing a recording example of a database subtransaction execution history table.

FIG. 11 is an explanatory diagram of a counter canceling method.

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 1 Computer 2 Application program 3 Database management system 4 OLTP package 5 Operating system 6 Log 7 Counter 8 Database

Claims (6)

[Claims] 1. A log for storing a transaction execution history, a counter for storing data that is only added or subtracted, and data other than data stored in the log and the counter in data used for business. And a transaction processing means for receiving an input message requesting a transaction and processing the transaction. 2. The apparatus according to claim 1, wherein the transaction processing means includes: (1) recording the input telegram in the log; (2) a database subtransaction for updating the database; and the counter. Starting a counter subtransaction for updating, (3) committing the counter subtransaction, (4) committing the database subtransaction, (5) writing the execution result of the transaction to the log. A transaction processing system that executes in the order of (1), (2), (3), (4), and (5). 3. The transaction processing system according to claim 2, wherein the counter has a canceling unit for canceling the updating of the counter after the counter subtransaction is committed. 4. The apparatus according to claim 3, further comprising recovery processing means for recovering an incomplete transaction, wherein said recovery processing means determines whether or not an execution history corresponding to said log is recorded. By detecting an incomplete transaction, when the database subtransaction of the detected incomplete transaction has already been committed, the execution result is recorded in the log so as to complete the incomplete transaction in a state of transaction completion, When the detected database sub-transaction of the incomplete transaction is not yet committed, the transaction for canceling the update of the counter and recording the execution result in the log so that the incomplete transaction is completed in a transaction failure state. Processing Stem. 5. The transaction processing system according to claim 1, wherein said transaction processing means limits the lock period of each record of said counter to only when accessing each said record. 6. A log for storing a transaction execution history, a counter for storing data that is only added or subtracted, and data other than data stored in the log and the counter among data used for business. A computer-readable recording medium carrying a program for causing a computer to function as a transaction processing system including a database for storing a transaction, and an input message requesting a transaction, and a transaction processing means for processing the transaction.