JPH03269740A - Transaction processing system - Google Patents

Abstract

PURPOSE:To shorten the response time of each transaction and to improve the throughput of a system by executing fundamental processings in juxtaposition or parallel in accordance with dependence relations of data and control among fundamental processings. CONSTITUTION:An inputted transaction ignites a corresponding node in a graph in a fundamental processing unit dependence relation graph 2 from a user interface part 1, and a graph execution part 4 executes the node of the graph by the indication from a suspend/resume mechanism part 3. That is, dependence relations of data and control among fundamental processing units are expressed with the graph, and fundamental processings are suspended (interrupted)/resumed (restarted) in accordance with the graph to simultaneously advance plural transaction processings. Thus, an unnecessary waiting time is eliminated because fundamental processings are operated in parallel (juxtaposition) in accordance with the data flow and the control flow among fundamental processings, and the response time of each transaction is shortened and the throughput of the system is improved.

Description

[Detailed Description of the Invention] [Overview] Regarding a transaction processing system that performs simultaneous execution control, the purpose is to improve the response time of each transaction and the throughput of the system. It is constructed by providing means for decomposing the basic processes and means for executing the basic processes in parallel or in parallel according to the dependence relationship of data and control between the basic processes.

[Industrial Field of Application] The present invention relates to control of concurrent execution of transactions in an information processing device (electronic computer). In transaction processing of a computer, the method of controlling concurrency greatly affects the performance of the system. The present invention relates to a transaction processing system that can perform such concurrent execution control efficiently and flexibly.

[Prior art] Whether it is a sequential computer or a parallel computer, the access speed and CP of external storage (hereinafter referred to as disk) are important.
Since there is a large difference in the processing speed of U, it is common to accept multiple transactions at the same time and perform disk access and CPU processing in parallel to increase system throughput.

At this time, one record in the database (it can be a table or a page; in the following description, a record is a table,
When multiple transactions (which can be replaced by pages) are updated almost simultaneously by multiple transactions, locks are used to perform exclusive control to prevent the updated content from being overwritten (data destruction).

This kind of control is called transaction concurrency control.

Concurrency control method improves system response and
Time and throughput will change.

That is, when a certain transaction locks a certain record, other transactions must suspend processing on that record until the lock is released.

If processing for several records is specified by a program and executed sequentially in a transaction, this interruption will not only worsen the response time of each transaction but also reduce system throughput. .

In this case, whether records with a high or low probability of being locked are processed first determines whether or not read-ahead can be performed on the disk, resulting in a difference in processing speed.

[Problem to be solved by the invention] As mentioned above, in concurrency control, processing speed changes depending on whether records that are more likely to be locked or records that are less likely to be locked are processed first. . Therefore, conventionally, in order to improve processing performance, a method has often been adopted in which lock dependencies are analyzed and processing is scheduled so that records are accessed in an appropriate order. However, as the processing becomes more complex, it becomes difficult to analyze lock dependencies, and a great deal of effort is required to create the system. Furthermore, the scheduling of such a system is not versatile and can only be used for the application targeted for adjustment.

[Means for Solving the Problems] According to the present invention, the above objects are achieved by the means described in the claims.

That is, in transaction processing by an electronic computer, the present invention provides means for decomposing a transaction into basic processing units, and means for executing basic processing in parallel or in parallel according to data and control dependencies between the basic processing. It is a transaction processing system.

[Function] In order to perform concurrent execution control flexibly and efficiently, the present invention proposes a method of decomposing a transaction into basic processing units and executing the transactions in parallel (parallel) in the basic processing units. Basic processing refers to locking, reading, changing contents, writing, etc. of records.

For efficient parallel processing, graph the data and control dependencies between basic processing units, suspend/resume basic processing according to the graph, and proceed with multiple transaction processing simultaneously. . This graph represents data flow and control flow.

By executing basic processing according to the graph in this way, the optimal execution order is dynamically determined.

Therefore, processes that do not need to wait for a lock will not wait until the lock that is the bottleneck for the process is released.
It can be advanced.

In other words, there is no need to include scheduling in consideration of lock dependencies in the program. Also, since you can create graphs for each application,
It also becomes more versatile.

Parallel language with suspend/resume mechanism (GHC)
, Parlog, Concurrent Prolo
By describing transaction processing in basic processing units using (e.g.), the transaction processing system described above can be easily realized.

[Example] The basic configuration of an embodiment of the present invention is shown in FIG.

In the figure, an incoming transaction fires a corresponding node in a graph prepared in advance in the basic processing unit dependency graph 2 from the user interface unit 1 (a graph is created at the time a transaction enters). There are other ways to do this.

The suspend/resume mechanism section 3 checks whether or not a graph node is firing, and notifies the graph execution section 4 of the fired graph node.

In the graph execution unit 4, the suspend/resume mechanism unit 3
Executes nodes in the graph according to instructions from When executing a database access node in the graph, an access request is issued to the database search/update section 5 in order to access the database 7.

Processing results are returned through the user interface section 1. If a lock is required for exclusive control, a lock request is issued to the lock mechanism section 6. At this time, if it is already locked, it waits for the lock to be released. Regarding deadlock, there is a method of detecting the deadlock using the locking mechanism section 6 and rolling back a transaction that started late.

Since nodes in the graph are executed dynamically based on the system state at that time, efficient processing with less unnecessary waiting is possible.

Next, consider an example of typical transaction processing with reference to FIG. In FIG. 2, 8 represents basic processing, 9 records, 10 lock relations, arrows 11 represent control flow, and arrows 12 represent data flow.

As shown in the figure, consider a transaction in which three records with IDs I+j+k in three databases a, b, and c are updated by adding delta to each record. Lock each record because it may be accessed by another transaction.

If you write the transaction sequentially, it will look like this:

5tart Transaction; 1ock (
a, i); x:=find (a, i); x: = x+ delta; replace (a, i, x); 1ock (b, j); y:=ftnd (b, J); y:” N-delta; replace (b, j, y); 1lock (c, k); z:= z+ delta; replace (c, ni, z); unlock (a, i): unlock (b, j); unlock (c, k); Commit Transactlon; Here, each record must be unlocked after all 1locks are completed according to the two-phase lock method.

If multiple similar transactions are running at the same time and access the same record, they will have to wait for the 1ock processing part. In particular, the record that was 1ocked at the beginning of the transaction (in this example,
If the conflict probability is high for the record with ID i in database a (hereinafter written as a, l record), the subsequent processing will be performed after that lock is released.
Transaction response becomes poor. If it is difficult to lock the records b and c, it is possible to proceed with the process and perform time-consuming disk access while unlocking the a and l records. However, when processing proceeds sequentially, a, l
Processing takes time because the record is unlocked and the remaining two records are accessed from the disk.

Therefore, we will consider a method to dynamically change the execution order. A graph of the dependencies of the basic processing units of the transactions in the above example is shown in Figure 11E3. In the same figure, 8
is the basic processing, 9 is the record, the bidirectional arrow 10 is related to locking, the arrow 11 is the control flow, and the arrow 12 is the data flow, and these are the same as in the case of Figure 2. It is. 5ync13 is for synchronization, and outputs when all inputs to that node are received.

Since the actual update must be performed at commit time, the update is performed after all lock processing in the transaction is completed, and the lock is released when all updates are completed. For this reason, synchronization is required.

As can be seen from Figure 3, searching for a and l records, and b
, l record, The search for the record in c can be done in parallel, independent of the locking of other records. Therefore, records with few conflicts can be automatically prefetched.

In order to execute this graph, we will consider a method using a parallel language with a suspend/resume mechanism. The mechanism of the system at this time is shown in FIG. That is, the user interface section, basic processing unit dependency relationship graph, suspend/resume mechanism, and graph execution portions of the basic configuration diagram are replaced with the GHC processing system 14.

In the case of such a system configuration, the GHC program for the transaction example shown in FIG. 3 is as follows. In the GHC program, a string starting with a capital letter indicates a variable, and the processing after the ; mark can be executed in parallel (parallel) starting from the determined value of the input variable.

transaction (1,J,Delta)
knee get time of day (Ti
me stamp): 1ock (a, I, Ti
me stamp, ^-1ock).

1ock (b, J, Time stamp, B 1
ock).

1ock (c, ni, Time stamp, C1o
ck).

find (^-1ock, a, I, ^-data
).

find(B 1ock, b, J, B data)
.

find (C1ock, c, to, Cdata).

modify (＾-data, Delta, 8-d
ata new).

modify (B data, Delta, B
data new).

modify(Cdata, Delta, Cdata
new).

ync ([^-1ock, B 1ock, C1ock],
L5ync).

replace (L 5ync, a, I, ^-data new,
8-5txt).

reprise (L 5ync, bj, B data new,
B5tat).

replace (L 5ync, c, K, Cdata ne
w, C5tat).

ync ([^-5tat, B 5tat, C5tat]
, S5ync).

unlock (S 5 sync, a, I).

unlock (S 5ync, b, J) + unl
ock(S 5ync, c, to).

In order to determine which transaction started earlier when a deadlock occurs, a time stamp is taken at the time of start (get tile of day) and passed to the locking mechanism. At this time, transactions that started late are roll packed and processing is restarted from the beginning. In addition, 5sync has two arguments to provide versatility, and a list of variables to be synchronized is passed as the first argument.

This program consists of 1. The operation starts when $ and Delta are given to J. GHC's suspend/resume mechanism causes each basic process to be executed in a dynamic order.

[Effects of the Invention] As explained above, according to the present invention, in transaction processing, unnecessary waiting time is eliminated by operating basic processes in parallel according to the data flow and control flow between the basic processes. Therefore, the response time of each transaction and the system throughput are improved. FIG. 5 is a diagram explaining the present invention in detail and shows a timetable in the case of multiple transactions, where (a) shows the case according to the method of the present invention and (b) shows the case according to the conventional method. ing.

Furthermore, since there is no need to specify the execution order according to lock dependencies, programming becomes easier and versatility increases. On the other hand, by using a parallel language system that has a suspend/resume mechanism, system configuration becomes easier. Using a parallel language with less switching overhead has the advantage of increasing processing efficiency.

[Brief explanation of drawings]

Figure 1 shows the basic configuration of an embodiment of the present invention, Figure 2 shows an example of transaction processing, Figure 3 shows an example of a dependency graph, and Figure 4 uses GHC. FIG. 5 is a diagram illustrating the effect of the present invention. 1...User interface section, 2...
- Basic processing unit dependency graph, 3... Suspend/resume mechanism section, 4... Graph execution section, 5... Database search/update section, 6...
... Lock mechanism section, 7 ... Database, 8
...Basic processing, 9...Record, lO
... Lock related, 11 ... Control flow, 12 ... Data flow, 13 ...5
ync. 14...GHC processing system

Claims (1)

[Claims] 1. In transaction processing by an electronic computer,
A transaction processing system comprising: means for decomposing transactions into basic processing units; and means for executing the basic processes in parallel or in parallel according to data and control dependencies between the basic processes. 2. The transaction processing system according to claim 1, wherein a plurality of basic processes are executed in parallel or in parallel by graphing data and control dependencies between basic processes of a transaction and suspending/resuming the basic processes according to the graph. . 3. Claim in which the system configuration comprises a user interface section, a basic processing unit dependency graph, a graph execution section, a lock mechanism section, a suspend/resume mechanism section, a database search/update section, and a database. 1
and the transaction processing system described in 2. 4. The transaction processing system according to claim 3, wherein the locking mechanism detects deadlock, determines a transaction that started late based on a time stamp, and rolls back the transaction. 5. The transaction processing system according to claim 3, wherein the suspend/resume mechanism section is implemented using a parallel language having a suspend/resume mechanism.