JP2008176687A - Transaction processing of database - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To allow high separability when performing distributed processing of transaction. <P>SOLUTION: A commit log 63 backs up values before commission of records operated in transactions committed in the past. A transaction operation part 41 comprising a CPU is accessible to the commit log 63 in a RAM and is accessible to a storage 2, and uses values of records in the commit log 63 in preference to those in the storage 2 to execute the transaction when reading a record. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to database transaction processing.

  A transaction is a series of operations executed as a unit of work for a database. When transactions are executed, atomicity, consistency, isolation and persistence need to be ensured.

  Atomicity means that only a series of operations can be performed or not performed at all.

  Consistency means that all data is kept consistent at the completion of a transaction.

  Separation means that a plurality of transactions handle data independently. There are multiple levels of isolation such as serializable and repeatable reads.

  Persistence means that the outcome of a transaction is maintained in the database.

  As an apparatus for executing a transaction, for example, there is one described in Patent Document 1. In this apparatus, when a transaction is executed, writing is performed on the transaction log, and reading is performed from the database. Transaction logs are written to disk storage with a database. At commit time, the contents of the transaction log are reflected in the database. At commit time, reading is done from the transaction log.

US Pat. No. 6,418,455

  In the above system, although a certain degree of separation is maintained, when a transaction is committed, the value of the record operated by the transaction in the database changes. Therefore, it is difficult to maintain a high degree of separation in the above system.

  For example, when a record is read in the other transaction after one of the two transactions started at the same time is committed, the record may not maintain the value at the start of the transaction.

  Also, for example, of two transactions started at the same time, a record is read in transaction # 2 before transaction # 1 is committed, and the same record is found in transaction # 2 after transaction # 1 is committed. If read again, different values may be read.

  An object of the present invention is to enable a high degree of separation when transactions are distributedly processed.

  In order to solve the above problems, the present invention is configured as follows.

  One of data processing apparatuses according to the present invention includes a processing apparatus that executes a transaction in a computer, an access means that is connected to the processing apparatus and accesses a storage in the computer, and a memory that is connected to the processing apparatus in the computer. Is provided. The memory stores a commit log. The commit log is data that backs up a value before committing of a record operated in a transaction committed in the past. In addition, the processing device can access the memory and access the storage via the access means, and when reading a certain record, the record value in the commit log is given priority over the record value in the storage. Use to execute a transaction.

  Thereby, even after another transaction commits, the record value at the start of the transaction can be obtained from the commit log in the memory. For this reason, a high degree of separation can be maintained when transactions are distributedly processed.

  In addition to the data processing apparatus described above, the data processing apparatus according to the present invention may be configured as follows. That is, in that case, the memory stores individual logs. The individual log has a value after the operation of the record operated in the transaction. Then, when reading a certain record, the processing device executes a transaction using the record value in the individual log with priority over the record value in the storage and commit logs.

  Thereby, when the record value is changed by execution of its own transaction, the record value is read from the individual log on the memory. For this reason, the frequency of accessing the storage is reduced, and transactions can be executed at high speed.

  The data processing apparatus according to the present invention may be as follows in addition to any of the data processing apparatuses described above. That is, in that case, the memory stores individual logs. The individual log has a value after the operation of the record operated in the transaction. Then, at the time of commit, the processing device reads the storage record corresponding to the record whose value is stored in the individual log, stores the storage record value as the commit log, and then reflects the value in the individual log to the storage record. Let

  The data processing apparatus according to the present invention may be as follows in addition to any of the data processing apparatuses described above. That is, in this case, the processing apparatus executes a plurality of transactions in parallel, and prohibits other transactions from being committed during backup processing to the commit log.

  The data processing apparatus according to the present invention may be as follows in addition to any of the data processing apparatuses described above. In other words, in that case, the processing apparatus can read a record from the storage or the commit log for another transaction during the backup process.

  Thereby, the period during which the record reading is locked is shortened, and the transaction processing time can be shortened.

  The data processing apparatus according to the present invention may be as follows in addition to any of the data processing apparatuses described above. That is, in this case, the processing apparatus generates an individual log for each transaction and erases the individual log of the committed transaction. The memory also stores an individual log for each transaction.

  As a result, an individual log of a certain transaction is not accessed from other transactions, and an address space can be made separate for each transaction, facilitating distributed processing.

  The data processing apparatus according to the present invention may be as follows in addition to any of the data processing apparatuses described above. In other words, in this case, the processing device can read a record from the storage, the commit log, and the individual log of another transaction for another transaction while executing a commit of a certain transaction.

  Thereby, the period during which the record reading is locked is shortened, and the transaction processing time can be shortened.

  The data processing apparatus according to the present invention may be as follows in addition to any of the data processing apparatuses described above. That is, in this case, the commit log is stored in the memory in order along the time series. When reading a record for a transaction, the processing device refers to the commit log after the start of the transaction, and if there is a commit log for the record, obtains the value of the record from the commit log .

  As a result, reference to the commit log is minimized, and record reading can be performed at high speed. For this reason, a transaction can be executed at high speed.

  One of the data processing apparatuses according to the present invention is capable of accessing a commit log for backing up a value before committing a record operated in a transaction committed in the past, a storage and a commit log, and reading a record. And a transaction processing means for executing a transaction by using the record value in the commit log in preference to the record value in the storage.

  As a result, the record value at the start of the transaction can be acquired from the commit log even after another transaction commits. For this reason, a high degree of separation can be maintained when transactions are distributedly processed.

  In addition to the data processing apparatus described above, the data processing apparatus according to the present invention may be configured as follows. That is, in this case, the data processing apparatus includes an individual log and a commit processing unit. The individual log has a value after the operation of the record operated in the transaction. The commit processing means reads a storage record corresponding to a record whose value is stored in the individual log, stores the storage record value in the commit log, and then reflects the value in the individual log in the storage record. Then, when reading a certain record, the transaction processing means executes the transaction using the record value in the individual log with priority over the record value in the storage and commit logs.

  Thereby, when the record value is changed by execution of its own transaction, the record value is read from the individual log on the memory. For this reason, the frequency of accessing the storage is reduced, and transactions can be executed at high speed.

  One of the transaction execution methods according to the present invention is that when a transaction is committed by a processing device, a value before committing a record operated in the transaction is stored in a memory as a commit log. When reading a record, the record value in the commit log is used in preference to the record value in the storage.

  As a result, the record value at the start of the transaction can be acquired from the commit log even after another transaction commits. For this reason, a high degree of separation can be maintained when transactions are distributedly processed.

  In addition to the above transaction execution method, the transaction execution method according to the present invention may be as follows. In other words, in this case, the processing device executes multiple transactions in parallel and prohibits other transactions from being committed during the backup process that backs up the pre-commit value of the record operated in the commit transaction to the commit log. To do.

  In addition to the above transaction execution method, the transaction execution method according to the present invention may be as follows. That is, in that case, the processing apparatus generates an individual log for each transaction, and erases the individual log of the committed transaction. In addition, an individual log is stored in the memory for each transaction.

  As a result, an individual log of a certain transaction is not accessed from other transactions, and an address space can be made separate for each transaction, facilitating distributed processing.

  In addition to the above transaction execution method, the transaction execution method according to the present invention may be as follows. That is, in this case, the commit log is stored in the memory in order along the time series. When a record is read out for a certain transaction, the commit log after the start time of the transaction is referred to. If there is a commit log for the record, the value of the record is acquired from the commit log.

  As a result, reference to the commit log is minimized, and record reading can be performed at high speed. For this reason, a transaction can be executed at high speed.

  One of the transaction execution methods according to the present invention includes a step of backing up a value before committing a record operated in the transaction to a commit log when a transaction is committed, and a case of reading a record in the transaction. If the value of the record is in the commit log, the value of the record in the commit log is used. If the value of the record is not in the commit log, the value of the record read from the storage is used.

  As a result, the record value at the start of the transaction can be acquired from the commit log even after another transaction commits. For this reason, a high degree of separation can be maintained when transactions are distributedly processed.

  When the transaction execution program according to the present invention commits a transaction by the processing device, the value before committing the record operated in the transaction is read from the storage and stored in the memory as a commit log. When reading a certain record, the record value in the commit log is used in preference to the record value in the storage.

  As a result, the record value at the start of the transaction can be acquired from the commit log even after another transaction commits. For this reason, a high degree of separation can be maintained when transactions are distributedly processed.

  In addition to the transaction execution program, the transaction execution program according to the present invention may be as follows. In other words, in this case, a plurality of transactions are executed in parallel, and the commit of other transactions is prohibited during the backup process of backing up the value before the commit of the record operated in the commit transaction to the commit log.

  Further, the transaction execution program according to the present invention may be as follows in addition to any of the transaction execution programs described above. That is, in this case, an individual log is generated for each transaction, the individual log of the committed transaction is deleted, and the individual log is stored in the memory for each transaction.

  As a result, an individual log of a certain transaction is not accessed from other transactions, and an address space can be made separate for each transaction, facilitating distributed processing.

  Further, the transaction execution program according to the present invention may be as follows in addition to any of the transaction execution programs described above. That is, in this case, the commit log is stored in the memory in order along the time series. When a record is read for a certain transaction, the commit log after the start time of the transaction is referred to. If there is a commit log for the record, the value of the record is obtained from the commit log.

  As a result, reference to the commit log is minimized, and record reading can be performed at high speed. For this reason, a transaction can be executed at high speed.

  In addition, when the transaction execution program according to the present invention commits a transaction, the step of backing up the value before committing of the record operated in the transaction to the commit log, and when reading a record in the transaction, the record If the value of the record is in the commit log, the value of the record in the commit log is used. If the value of the record is not in the commit log, the step of using the value of the record read from the storage is executed.

  As a result, the record value at the start of the transaction can be acquired from the commit log even after another transaction commits. For this reason, a high degree of separation can be maintained when transactions are distributedly processed.

  According to the present invention, it is possible to maintain a high degree of separation when a transaction is distributedly processed.

  Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

  FIG. 1 is a block diagram showing a configuration of a database system according to an embodiment of the present invention. In FIG. 1, a server apparatus 1 is an embodiment of a data processing apparatus of the present invention. As the server device 1, a computer system having a program is used. The storage 2 is a data storage device that stores data as “records”. The storage 2 includes an interface that communicates with the server device 1 and a recording medium that physically records data. For the storage 2, devices such as a hard disk drive, a disk array, and a file server are used.

  The server device 1 includes a CPU 11, a ROM 12, a RAM 13, a hard disk drive 14, an interface 15, a communication device 16, and an interface 17. In the server device 1, the CPU 11, the ROM 12, the RAM 13, and the like constitute a computer.

  A CPU (Central Processing Unit) 11 is a processing device that executes a program previously stored in the ROM 12 or the hard disk drive 14 and loaded into the RAM 13 and executes processing described in the program.

  A ROM (Read Only Memory) 12 is a nonvolatile memory that stores programs and data in advance. A RAM (Random Access Memory) 13 is a memory that temporarily stores the program and data when the program is executed.

  An HDD (Hard Disc Drive) 14 is a hard disk drive as a recording medium for storing an operating system (not shown) and an application program such as a program 21 as a database engine. Note that a drive device that stores the program 21 in a portable recording medium such as a CD-ROM or DVD-ROM and reads the program from the portable recording medium may be provided instead of the HDD 14.

  The interface 15 is an interface circuit as an access means that can access the storage 2. As the interface 15, a communication device such as a peripheral device interface or a network interface is used. As interfaces for peripheral devices, there are SCSI (Small Computer System Interface), IDE (Integrated Device Electronics) compatible, IEEE 1394, USB (Universal Serial Bus), and the like. Examples of the network interface include Ethernet (registered trademark).

  The communication device 16 is a device used for communication with an external device such as a network interface card or a modem. If the interface 15 is a network interface, the interface 15 may be used instead of the communication device 16. The communication device 16 communicates with one or more external client devices that supply transactions via a communication line.

  The CPU 11, the ROM 12, the RAM 13, the HDD 14, the interface 15, and the communication device 16 are connected to each other by a bus, a bridge controller, or the like in one computer. These connection forms are not particularly limited.

  For example, when this system is realized by using a server computer or the like, a motherboard to which the CPU 11 or the like is connected is arranged in the server computer casing, and the storage 2 is connected to the server computer via an interface. The

  Next, the processing unit and data structure realized when the program 21 is executed by the CPU 11 will be described. FIG. 2 is a block diagram showing a processing unit and a data structure in the data processing apparatus of FIG.

  In FIG. 2, a transaction calculation unit 41 is a calculation unit as transaction processing means for performing a series of operations and calculations in one transaction. Examples of commands in transactions include SELECT, UPDATE, INSERT, and DELETE. When executing a SELECT command for reading a record, the transaction operation unit 41 refers to the storage 2, the individual log 51, and the commit log 63, and performs data reading while maintaining separation. The transaction context 42 is data in one transaction. The transaction context 42 has an individual log 51 and commit log reference information 52. The individual log 51 is data having information on a record in which a change (update, insertion or deletion) has occurred in a transaction. The individual log 51 is local data of each transaction and is not accessed from other transactions. The commit log reference information 52 is a pointer (data) that points to the first (latest) commit log 63 at the time of occurrence of a transaction in one or a plurality of commit logs 63 arranged in time series. The transaction context 42 is stored in the RAM 13.

  One transaction calculation unit 41 and one transaction context 42 constitute a transaction processing unit 61 that processes one transaction. When an operating system that supports multithreading is used, one thread is assigned to one transaction processing unit 61.

  The transaction manager 62 is a processing unit that generates a transaction processing unit 61 when a transaction occurs and erases the transaction processing unit 61 when the transaction is completed. The transaction manager 62 is a processing unit as a commit processing unit that backs up the record value to the commit log 63 and writes to the storage 2 when the transaction is committed.

The commit log 63 is data that backs up the value before the change of the record in which the value has changed in the committed transaction. The commit log 63 is stored in the RAM 13 in the order of occurrence, one for each change.

  Next, an example in which the configuration in FIG. 2 is implemented based on an object-oriented language such as C ++ or C # will be described. FIG. 3 is a block diagram illustrating a specific example of the processing unit and the data structure in FIG.

  One transaction processing unit 61 in FIG. 2 is implemented by a pair of transaction context (TC) class instances 81 and individual log buffer (OLB) class instances 82 in FIG. One TC class instance 81 and one OLB class instance 82 are generated for each transaction.

  The TC class instance 81 has a method 91 and pointers 92 to 95 as data. The method 91 corresponds to the transaction calculation unit 41. The method 91 includes an insert method for executing an INSERT instruction, a delete method for executing a DELETE instruction, an update method for executing an UPDATE instruction, and a select method for executing a SELECT instruction. The pointer 94 corresponds to the commit log reference information 52. The pointer 92 is a pointer to the OLB class instance 82. A pointer 93 is a pointer to the transaction manager (TM) class instance 83. The pointer 95 is a pointer to the storage class instance 85.

  The OLB class instance 82 includes a method 101 and an insertion log 102, an update log 103, and a deletion log 104 as data. The insertion log 102, the update log 103, and the deletion log 104 are individual logs 51, respectively. The method 101 includes an insert method for adding the insertion log 102, an update method for adding the update log 103, a delete method for adding the deletion log 104, and the like. When the INSERT instruction is executed in a transaction corresponding to the OLB class 82, the insert method of the TC class instance 81 and the OLB class instance 82 is called and the insertion log 102 is added. When the UPDATE instruction is executed in a transaction corresponding to the OLB class 82, the update method of the TC class instance 81 and the OLB class instance 82 is called, and the update log 103 is added. When the DELETE instruction is executed in the transaction corresponding to the OLB class 82, the delete method of the TC class instance 81 and the OLB class instance 82 is called, and the deletion log 104 is added.

  The transaction manager 62 in FIG. 2 is implemented by the TM class instance 83 in FIG. There is only one TM class instance 83 for every TC class instance. The TM class instance 83 has a begin method for generating the TC class instance 81, a commit method for committing a transaction, a rollback method for rolling back the transaction, and the like as methods 111, and pointers 112 to 114 as data. Each of the one or more pointers 112 is a pointer to each TC class instance 81. The pointer 113 is a pointer to the commit log buffer (CLB) class instance 84. The pointer 114 is a pointer to the storage class instance 85.

  The commit log 63 in FIG. 2 is implemented by the CLB class instance 84 in FIG. The CLB class instance 84 has an insertLog method for adding a commit log 63 as a method 121, and has a pointer 122 and a series of commit logs 63 as data. The pointer 122 is a pointer to the head (latest) commit log 63 in the series of commit logs 63.

  Also, the input / output of each processing unit in FIG. 2 to the storage 2 is implemented by the storage class instance 85 in FIG. The storage class instance 8 provides a data input / output function in units of records as a method 131. The method 131 includes a readFirst method for reading the first record, a readNext method for reading the second and subsequent records, a delete method for deleting records, an update method for updating record values, and an insert method for inserting records.

  Here, the format of each data in this embodiment will be described. FIG. 4A to FIG. 4F are diagrams showing an example of the data format in this embodiment.

  As shown in FIG. 4A, the field is a data unit having data and its length. Next, as shown in FIG. 4B, a record is a data unit having a record identifier oid, a field number num-fields, padding nullBytes for adjusting the length of the record, and one or more fields. For example, the data length of oid is 4 bytes, the data length of num-fields is 2 bytes, and the data length of nullBytes is (num-fields) / 8 bytes. A unique value is assigned to the record as the identifier oid. The value of the field number num-fields is the number of fields in the record. The values of padding nullBytes are all null (usually zero).

  As shown in FIG. 4C, the commit log is composed of an attribute type and a record. The value of the attribute type is a value (for example, 1, 2, 3) corresponding to each of insertion, update, and deletion. In the case of update or deletion, the value of the record in the commit log is the value of the record in the storage 2 before committing, and in the case of insertion, the value is null (oid = 0, num-fields = 0, nullBytes = 0). .

  Also, as shown in FIGS. 4D to 4F, among the individual logs 51, the insertion log 102 (FIG. 4D) and the update log 103 (FIG. 4F) are inserted and Stores the updated record value. Only the identifier oid of the deleted record is stored in the deletion log 104 (FIG. 4E).

  Next, the operation of the above apparatus will be described.

  First, the program 21 of the HDD 14 is loaded into the RAM 13 and the CPU 11 starts executing the program 21. Thereby, first, a TM class instance 83, a CLB class instance 84, and a storage class instance 85 are generated.

  When a transaction is received from one or a plurality of external client devices (not shown) via the communication device 16, the CPU 11 executes the transaction according to the program 21 as follows. FIG. 5 is a flowchart for explaining transaction processing in the server apparatus of FIG.

  When one transaction is received, first, the transaction manager 62 generates one transaction processing unit 61 including the transaction context 42 (step S1). At that time, a TC class instance 81 and an OLB class instance 82 are generated by the begin method of the TM class instance 83.

  Next, the transaction is executed by the transaction calculation unit 41 (step S2). The transaction calculation unit 41 executes record operations and calculations described in the transaction. There are four arithmetic operations. Record operations include reading, updating, inserting and deleting records in the database. Reading a record is executed as a SELECT process, updating a record is executed as an UPDATE process, inserting a record is executed as an INSERT process, and deleting a record is executed as a DELETE process.

  At this time, the SELECT process is executed by the select method of the TC class instance 81, and the value of the record stored in any of the storage 2, the individual log 51, and the commit log 63 is the return value (that is, the read value). Is done.

  In the SELECT process, in order to ensure separation, the value of the record in the storage 2 needs to be maintained at the value of the record when the transaction occurs. As will be described later, in this embodiment, when the record value in the storage 2 is changed by another committed transaction, the record value at the time of the transaction occurrence is backed up in the commit log 63. . Therefore, when a record to be subjected to SELECT processing is stored in the commit log 63, the value of the record in the commit log 63 is preferentially used. At that time, only the commit log 63 after the transaction occurrence time is referred to, and the record value before the transaction occurrence time is not used. Further, when the value of the record is changed by itself after the transaction is started and then the record is read, the value of the record in the individual log 51 is used.

  The UPDATE process is executed by the update method of the TC class instance 81, and the updated record value is added to the update log 103 of the individual log 51. The INSERT process is executed by the insert method of the TC class instance 81, and the value of the inserted record is added to the insertion log 102 of the individual log 51. The DELETE process is executed by the delete method of the TC class instance 81, and the identifier of the deleted record is added to the deletion log 104 of the individual log 51. In the UPDATE process, the INSERT process, and the DELETE process, access to the storage 2 does not occur, and only access to the RAM 13 occurs.

  When the record operation and calculation described in the transaction are completed, the transaction manager 62 executes a commit process (step S3). The commit process is executed by the commit method of the TM class instance 83. In this database system, in the commit process, before reflecting the value of the record that has been changed by the execution of the transaction to be committed from the individual log 51 to the storage 2, the value of that record in the storage 2 is backed up to the commit log 63. To do. Then, after backup, the value of the record in the individual log 51 is reflected on the value of the corresponding record in the storage 2. After the commit process is executed in this way, the transaction manager 62 deletes the transaction processing unit 61 of the committed transaction. That is, the TC class instance 81 and the OLB class instance 82 of the transaction are deleted.

  As described above, one transaction is processed. When a plurality of transactions are received, the plurality of transactions are processed as described above in parallel.

  In this database system, by using the individual log 51 and the commit log 63, changes generated in the transaction are held in the transaction, and the record value is not affected by the commit of another transaction. For this reason, in a database system in which a plurality of transactions are executed in parallel, each transaction is executed based on the state of the record at the start of execution.

  When a plurality of transactions are processed, for example, distributed processing is performed by a plurality of threads. In processing other than SELECT, data access to the outside of the threads such as the commit log 63 and the storage 2 does not occur, so transaction processing is executed at high speed.

  Next, details of the above-described transaction context generation (step S1), UPDATE processing, INSERT processing, DELETE processing, SELECT processing, and commit processing (step S3) will be described.

  1. Transaction context generation

  FIG. 6 is a flowchart for explaining transaction context generation according to the embodiment of the present invention. Transaction context generation is executed by the begin method of the TM class instance 83.

  First, a TC class instance 81 is generated (step S11). Then, a pointer 112 to the TC class instance 81 is added to the TM class instance 83 (step S12).

  Next, the CLB class instance 84 is locked (step S13). The value of the pointer 123 in the CLB class instance at that time is set in the pointer 94 of the TC class instance 81 (step S14). Thereafter, the lock of the CLB class instance 84 is released (step S15). As a result, the pointer value to the first commit log 63 at the time of generating the transaction context, that is, at the start of the transaction is set to the pointer 94 in the TC class instance 81.

  Then, an OLB class instance 82 is generated (step S16), and a pointer value to the OLB class instance 82 is set in the pointer 92 of the TC class instance (step S17). Thereby, the correspondence between the TC class instance 81 and the OLB class instance 82 is established.

  In this way, one TC class instance 81 and one OLB class instance 82 are generated corresponding to one transaction, and data initialization is performed.

  2. UPDATE processing

  FIG. 7 is a flowchart for explaining the UPDATE process according to the embodiment of the present invention. The UPDATE process is executed by the update method of the TC class instance 81 and the OLB class instance 82. In the UPDATE process, a record designated as an argument of the update method is added to the update log 103 of the OLB class instance 82 (step S21). Therefore, no access to the storage 2 occurs in the UPDATE process.

  3. INSERT processing

  FIG. 8 is a flowchart for explaining the INSERT processing according to the embodiment of the present invention. The INSERT process is executed by the insert method of the TC class instance 81 and the OLB class instance 82. In the INSERT process, a record designated as an argument of the insert method is added to the insertion log 102 of the OLB class instance 82 (step S31). Therefore, access to the storage 2 does not occur in the INSERT process.

  4). DELETE processing

  FIG. 9 is a flowchart for explaining the DELETE process according to the embodiment of the present invention. The DELETE process is executed by the delete method of the TC class instance 81 and the OLB class instance 82. In the DELETE process, a record designated as an argument of the delete method is added to the deletion log 104 of the OLB class instance 82 (step S41). Therefore, no access to the storage 2 occurs in the DELETE process.

  5. SELECT processing

  FIG. 10 is a flowchart illustrating the SELECT process according to the embodiment of the present invention. The SELECT process is executed by the select method of the TC class instance 81.

  In the SELECT process, one or more records are specified as an argument of the select method. Then, the designated first record is read from the storage 2 (step S51).

  When the record exists, that is, when the record is successfully read (step S52), it is confirmed by referring to the individual log 51 whether the record has been updated (step S53). If the record has not been updated (step S54), it is confirmed with reference to the individual log 51 whether the record has been deleted (step S55).

  If the record has not been deleted (step S56), it is confirmed by referring to the commit log 63 whether the record has been updated (step S57). If the record has not been updated (step S58), it is confirmed by referring to the commit log 63 whether the record has been inserted (step S59).

  If the record is not inserted (step S60), the value of the record read from the storage 2 is saved (step S61). That is, when there is no log of the record in either the individual log 51 or the commit log 63, the record value read from the storage 2 is used as the value of the record targeted for SELECT processing.

  On the other hand, when it is determined that the record is updated based on the individual log 51 (step S54), the value of the record is changed to the updated record value in the individual log 51 (step S62) and saved. The That is, when there is an update log 103 of the record, the record value in the update log 103 is used as the value of the record to be subjected to SELECT processing.

  If it is determined that the record has been deleted based on the individual log 51 (step S56), the record reading process ends without saving the record. That is, null is returned as the return value of the reading process, and reading of the record has failed.

  Further, when it is determined that the record has been updated based on the commit log 63 (step S58), the value of the record is changed to the record value in the commit log 63 (step S63) and stored. That is, when there is a commit log 63 whose attribute is “update” for the record, the record value in the commit log 63 is set as the value of the record that is the subject of the SELECT process.

  If it is determined that the record is inserted based on the commit log 63 (step S60), the record reading process is terminated without saving the record. That is, null is returned as the return value of the reading process, and reading of the record has failed.

  If the record does not exist in the storage 2 (step S52), the record reading process ends. That is, null is returned as the return value of the reading process, and reading of the record has failed.

  When the reading process for the first record is completed, the next record is read (step S64). FIG. 11 is a flowchart for explaining the processing in step S64 in FIG.

  When reading the next record, first, the next record is read from the storage 2 (step S71). When the record exists in the storage 2 (that is, when reading from the storage 2 succeeds), the record value is regarded as the value in the storage 2 of the next record and used (step S73).

  On the other hand, when the record does not exist in the storage 2, the record is read from the insertion log 102 of the individual log 51 (step S75). When the record exists in the insertion log 102, the record value is regarded as the value in the storage 2 of the next record and used (step S76).

  If the record does not exist in the insertion log 102, the record is read from the “delete” attribute log of the commit log 63 (step S77). If the record exists in the “delete” attribute log of the commit log 63, the record value is used as the value of the next record in the storage 2 (step S79).

  If the record does not exist in the “deleted” attribute log of the commit log 63, it is determined that the record does not exist (step S80). That is, null is returned as a return value.

  If there is a record to be read, the processes of steps S53 to S61 are executed for that record.

  Then, the reading process is repeatedly executed until there are no more records to be read. When there are no more records to be read (step S65), the SELECT process ends.

  6). Commit processing

  FIG. 12 is a flowchart illustrating the commit process according to the embodiment of the present invention. The commit process is executed by the commit method of the TM class instance 83.

  First, the commit process of another transaction is locked. That is, when transaction commit processing is executed, commit processing of other transactions is limited (step S91). In the locked state, the commit process of another transaction cannot be started during the commit process of a certain transaction. Note that the commit processing of other transactions is limited, but other processing (such as SELECT processing) for other transactions is not limited.

  Next, the CLB class instance 84 is locked (step S92). In this state, access to the CLB class instance 84 for other transactions is restricted.

  Then, the record of the deletion log 104 of the individual log 51 is backed up from the storage 2 to the commit log 63 (step S93). FIG. 13 is a flowchart for explaining backup of a record designated by the deletion log 104 according to the embodiment of this invention. First, one deletion log 104 is read (step S111). When the deletion log 104 exists (step S112), the identifier oid of the record to be deleted is acquired from the deletion log 104 (step S113). Next, the record with the acquired identifier oid is read from the storage 2 (step S114). The commit log 63 is generated by adding the “delete” attribute type to the record (step S115). The generated commit log 63 is added to the CLB class instance 84 (step S116). Then, the processes in steps S111 to S116 are executed in order for each deletion log 104 until they are executed for all the deletion logs 104.

  Further, the record of the update log 103 of the individual log 51 is backed up from the storage 2 to the commit log 63 (step S94). FIG. 14 is a flowchart for explaining backup of a record specified by the update log 103 according to the embodiment of this invention. First, one update log 103 is read (step S121). When the update log 103 exists (step S122), the identifier oid of the record to be updated is acquired from the update log 103 (step S123). Next, the record with the acquired identifier oid is read from the storage 2 (step S124). The commit log 63 is generated by adding an “update” attribute type to the record (step S125). The generated commit log 63 is added to the CLB class instance 84 (step S126). Then, the processes in steps S <b> 121 to S <b> 126 are sequentially performed on each update log 103 until the processes are performed on all the update logs 103.

  Further, the record of the insertion log 104 of the individual log 51 is backed up to the commit log 63 (step S95). FIG. 15 is a flowchart for explaining backup of a record designated by the insertion log 102 in the embodiment of the present invention. First, one insertion log 102 is read (step S131). If the insertion log 102 exists (step S132), the identifier oid of the record to be inserted is acquired from the insertion log 102 (step S133). Next, the commit log 63 is generated by adding the “insert” attribute type to the record whose value is null (oid = 0, num-fields = 0, nullBytes = 0) (step S134). The generated commit log 63 is added to the CLB class instance 84 (step S135). Then, the processing of steps S131 to S135 is sequentially executed for each insertion log 102 until it is executed for all the insertion logs 102.

  In this way, the value before committing the operated record is backed up to the commit log 63. Then, the lock of the CLB class instance 84 is released (step S96).

  Thereafter, the deletion log 104 of the individual log 51 is reflected in the storage 2 record for the storage 2 (step S97). That is, the record specified by the identifier oid of the deletion log 104 is deleted from the storage 2. Further, the update log 103 of the individual log 51 is reflected in the record of the storage 2 designated by the identifier oid (step S98). That is, the record of the update log 103 is written to the storage 2. Further, the insertion log 102 of the individual log 51 is reflected in the storage 2 record designated by the identifier oid (step S99). That is, the record of the insertion log 102 is written to the storage 2.

  Thus, after the backup of the record value before the operation and the reflection of the record after the operation are completed, the lock of the commit process of the other transaction is released (step S100). When the commit process is completed, the committed TC class instance 81 and OLB class instance 82 are deleted.

  As described above, according to the above-described embodiment, the RAM 13 stores the commit log 63 that backs up the pre-commit value of the record operated in the transaction committed in the past. Further, the CPU 11 can access the RAM 13 and can access the storage 2 via the interface 15, and when reading a certain record, the record value in the commit log 63 has priority over the record value in the storage 2. And use it to execute transactions.

  As a result, the record value at the start of the transaction can be acquired from the commit log 63 even after another transaction commits. For this reason, a high degree of separation can be maintained when transactions are distributedly processed.

  Further, according to the above embodiment, the RAM 13 stores the individual log 51. The individual log 51 has a value after the operation of the record operated in the transaction. When a transaction is executed, when a certain record is read, the record value in the individual log 51 is used in preference to the record value in the storage 2 and the commit log 63.

  As a result, when the record value is changed by executing its own transaction, the record value is read from the individual log 51 in the RAM 13. For this reason, the frequency of accessing the storage 2 is reduced, and transactions can be executed at high speed.

  Further, according to the above-described embodiment, it is possible to read records from the storage 2 or the commit log 63 for other transactions during the backup process.

  Thereby, the period during which the record reading is locked is shortened, and the transaction processing time can be shortened.

  Further, according to the above embodiment, the individual log 51 is generated for each transaction, and the individual log 51 of the committed transaction is deleted. The RAM 13 stores an individual log 51 for each transaction.

  Thereby, the individual log 51 of a certain transaction is not accessed from other transactions, the address space can be made different for each transaction, and distributed processing is facilitated.

  Further, according to the above-described embodiment, when a commit process of a certain transaction is executed, a record can be read from the storage 2, the commit log 63, and the individual log 51 of another transaction for another transaction. is there.

  Thereby, the period during which the record reading is locked is shortened, and the transaction processing time can be shortened.

  Further, according to the above embodiment, the commit log 63 is stored in the RAM 13 in order along the time series. When a record is read for a transaction, only the commit log 63 after the transaction start time is referred to. If there is a commit log 63 for the record, the value of the record is acquired from the commit log 63.

  Thereby, the reference to the commit log 63 is minimized, and the record can be read at high speed. For this reason, a transaction can be executed at high speed.

  The above-described embodiments are preferred examples of the present invention, but the present invention is not limited to these, and various modifications and changes can be made without departing from the scope of the present invention. is there.

  For example, the server device 1 and the storage 2 may be connected via a computer network. In that case, a network interface or the like is used as the interface 15. For example, a server device 1 that receives a transaction, a storage 2, and a plurality of client devices that transmit a transaction may be connected to one LAN.

  In the embodiment described above, the server apparatus 1 has one CPU 11, but a plurality of transactions may be distributedly processed by a plurality of CPUs using a shared memory. Further, the distributed processing may be performed by the CPU 11 having a plurality of cores.

  Alternatively, the maximum number of commit logs 63 may be determined in advance, and when the number of commit logs 63 reaches the maximum number, the oldest commit log 63 may be deleted and the next commit log 63 may be added.

  Further, the commit log 63 before the start time of the oldest transaction among the existing transactions may be deleted at a timing such as when a transaction occurs, when a transaction is erased, or periodically.

  The present invention is applicable to, for example, a database engine.

It is a block diagram which shows the structure of the database system which concerns on embodiment of this invention. 2 is a block diagram illustrating a processing unit and a data structure in the data processing apparatus of FIG. 1. It is a block diagram which shows the specific example of the process part in FIG. 2, and a data structure. It is a figure which shows an example of the data format in this embodiment. It is a flowchart explaining the transaction process in the server apparatus of FIG. It is a flowchart explaining the transaction context production | generation in embodiment of this invention. It is a flowchart explaining the UPDATE process in embodiment of this invention. It is a flowchart explaining the INSERT process in embodiment of this invention. It is a flowchart explaining the DELETE process in embodiment of this invention. It is a flowchart explaining the SELECT process in embodiment of this invention. It is a flowchart explaining the process of step S64 of FIG. It is a flowchart explaining the commit process in embodiment of this invention. It is a flowchart explaining the backup of the record designated by the deletion log in embodiment of this invention. It is a flowchart explaining the backup of the record designated by the update log in embodiment of this invention. It is a flowchart explaining the backup of the record designated by the insertion log in embodiment of this invention.

Explanation of symbols

1 Server device (data processing device)
2 Storage 11 CPU (Processor)
13 RAM (memory)
15 Interface (access means)
41 Transaction calculation unit (transaction processing means)
51 Individual log 62 Transaction manager (commit processing means)
63 Commit log

Claims (20)

In a data processing device accessible by a computer to a storage having at least one record,
A processing device for executing a transaction in the computer;
An access means for accessing the storage connected to the processing device in the computer;
A memory connected to the processing unit in the computer;
With
The memory stores a commit log that backs up an uncommitted value of a record operated in a transaction committed in the past,
When the processing device is accessible to the memory and is accessible to the storage via the access means and reads a record, the value of the record in the commit log is determined from the value of the record in the storage. To prioritize and execute transactions,
A data processing apparatus. The memory stores an individual log having a value after operation of a record operated in a transaction,
The processing device, when reading a certain record, executes a transaction using a record value in the individual log in preference to a record value in the storage and the commit log;
The data processing apparatus according to claim 1. The memory stores an individual log having a value after operation of a record operated in a transaction,
The processing device reads a record of the storage corresponding to a record whose value is stored in the individual log at the time of commit, stores the value of the storage record as the commit log, and then sets the value in the individual log as the value of the individual log. Reflecting to storage records,
The data processing apparatus according to claim 1.   The processing device executes a plurality of transactions in parallel, and prohibits other transactions from being committed during a backup process that backs up the pre-commit value of a record operated in a commit transaction to the commit log. The data processing apparatus according to claim 1, wherein:   The data processing apparatus according to claim 4, wherein the processing apparatus is capable of reading a record from the storage or the commit log for the other transaction during the backup process. The processing device generates an individual log for each transaction, erases the individual log of the committed transaction,
The memory stores a separate log for each transaction;
The data processing apparatus according to claim 4.   The processing apparatus is capable of executing reading of a record from the storage, the commit log, and an individual log of the other transaction for another transaction while executing a commit of the transaction. The data processing apparatus according to claim 6. The commit log is stored in the memory sequentially in time series,
When reading a record for a transaction, the processing device refers to the commit log after the start time of the transaction, and if the commit log for the record exists, the value of the record from the commit log. To get the
The data processing apparatus according to claim 1. In a data processing apparatus accessible to a storage having at least one record,
A commit log that backs up the pre-commit value of the record that was manipulated in a previously committed transaction;
Transaction processing means that can access the storage and the commit log, and executes a transaction by using a record value in the commit log in preference to a record value in the storage when reading a record;
A data processing apparatus comprising: An individual log with the post-operation values of the records operated on in the transaction;
Commit processing for reading the storage record corresponding to the record whose value is stored in the individual log, storing the storage record value in the commit log, and then reflecting the value in the individual log to the storage record Means and
The transaction processing means, when reading a certain record, executes a transaction using the record value in the individual log in preference to the record value in the storage and the commit log;
The data processing apparatus according to claim 9. In a transaction execution method for executing a transaction by operating at least one record in a storage using a computer having a processing device for executing a transaction and a memory connected to the processing device,
When the transaction is committed by the processing device, the value before the commit of the record operated in the transaction is read from the storage and stored in the memory as a commit log,
When reading a certain record in a transaction by the processing device, the record value in the commit log is used in preference to the record value in the storage.
A transaction execution method characterized by the above.   The processing device executes a plurality of transactions in parallel, and prohibits the commit of other transactions during the backup process that backs up the pre-commit value of the record operated in the commit transaction to the commit log. The transaction execution method according to claim 11, wherein: The processing device generates an individual log for each transaction,
The individual log of committed transactions is deleted by the processing device,
Storing an individual log for each transaction in the memory;
The transaction execution method according to claim 12. The commit log is stored in the memory sequentially in time series,
When reading a record for a transaction, refer to the commit log after the start of the transaction,

If the commit log for the record exists, obtaining the value of the record from the commit log;
The transaction execution method according to claim 11. In a transaction execution method for executing a transaction by operating at least one record in storage,
When committing a transaction, backing up the pre-commit value of the record operated on in the transaction to a commit log;
When reading a record in a transaction, if the record value is in the commit log, the record value in the commit log is used, and if the record value is not in the commit log, the record is read from the storage. Using the value of the selected record,
A transaction execution method comprising: A computer having a processing device for executing a transaction and a memory connected to the processing device;
When the transaction is committed by the processing device, the value before the commit of the record operated in the transaction is read from the storage and stored in the memory as a commit log,
When reading a certain record in a transaction by the processing device, the record value in the commit log is used in preference to the record value in the storage;
A transaction execution program characterized by:   A plurality of transactions are executed in parallel, and committing of other transactions is prohibited during a backup process of backing up a value before commit of a record operated in a transaction to be committed to the commit log. 16. The transaction execution program according to 16. Generate a separate log for each transaction,
Clear the individual logs of committed transactions,
Storing an individual log for each transaction in the memory;
The transaction execution program according to claim 17. The commit log is stored in the memory sequentially in time series,
When reading a record for a transaction, the commit log after the start time of the transaction is referred to.
If the commit log for that record exists, get the value of that record from the commit log;
The transaction execution program according to claim 16. In a transaction execution program that causes a computer to execute a transaction by operating at least one record in a storage,
When committing a transaction, backing up the pre-commit value of the record operated on in the transaction to a commit log;
When reading a record in a transaction, if the record value is in the commit log, the record value in the commit log is used, and if the record value is not in the commit log, the record is read from the storage. Using the value of the selected record,
A transaction execution program characterized in that the program is executed.

Images