Transaction processing method and computer system

Abstract

The embodiment of the present application provides a transaction processing method and a computer system. Among them, when the first transaction is started, the storage space corresponding to the first transaction is requested from the persistent storage medium; the storage address of the storage space is recorded for at least one data object updated by the first transaction; when the first transaction is committed, the transaction commit identifier of the first transaction is generated; the transaction commit identifier is stored in the storage space; for the second transaction that performs data query, a view of the second transaction is constructed based on the most recently generated transaction commit identifier; according to the transaction commit identifier in the view and the transaction commit identifier indexed by the storage address recorded by different versions in the version chain of the target data object, the visible version of the second transaction is searched from the version chain; the embodiment of the present application improves transaction processing performance.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of data processing technology, and in particular, to a transaction processing method and a computer system. Background Art

[0002] A transaction is a set of operations in a database system that is used to access and possibly manipulate data objects.

[0003] In actual applications, there are situations where multiple transactions are executed concurrently. Database systems usually use concurrency control mechanisms to limit different transactions from accessing and updating the same data object. For example, by using a multi-version concurrency control mechanism, by maintaining multiple versions of data objects, the database system can allow transactions to read historical versions of data objects when the data objects are updated by other transactions. One specific implementation method is to maintain two memory data structures in memory by locking them: the active transaction set and the active view linked list. When a write transaction starts, two memory data structures are locked, and a transaction identifier is generated and inserted into the active transaction set. When a transaction updates a data object, the old version of the data object is stored in the rollback log, the data object is updated, and the transaction identifier is recorded in the data object to identify the transaction that updated the data object. When a transaction is committed, the two memory data structures are also locked, and the transaction identifier is deleted from the active transaction set. When a read transaction queries data, the two memory data structures are also locked, and the currently surviving transaction identifiers in the active transaction set are copied to build a view, and the view is inserted into the active view linked list. The read transaction searches for and accesses the visible version from the different versions corresponding to the target data object requested for query, based on the minimum transaction identifier and maximum transaction identifier in the view it builds, combined with the transaction identifiers recorded in the different versions. The transaction identifier recorded in the visible version is required to be less than the minimum transaction identifier or not included in the currently surviving transaction identifier set corresponding to the view.

[0004] From the above description, it can be seen that in the existing method, locks need to be used for a long time to maintain two complex memory data structures, which is easy to cause lock contention problems, especially in mixed read-write scenarios, resulting in reduced processing performance. Summary of the invention

[0005] The embodiments of the present application provide a transaction processing method and a computer system to solve the technical problem of low processing performance in the prior art.

[0006] In a first aspect, an embodiment of the present application provides a transaction processing method, including:

[0007] When a first transaction is started, applying for storage space corresponding to the first transaction from a persistent storage medium;

[0008] Recording the storage address of the storage space for at least one data object updated by the first transaction respectively;

[0009] When the first transaction is committed, generating a transaction commit identifier of the first transaction;

[0010] The transaction commit identifier is stored in the storage space; wherein the storage space is used to query the transaction commit identifier of the first transaction, and the transaction commit identifier of the first transaction is used to find a visible version of the target data object requested to be queried by the second transaction.

[0011] In a second aspect, an embodiment of the present application provides a transaction processing method, including:

[0012] Building a view of the second transaction based on the most recently generated transaction commit identifier;

[0013] According to the transaction commit identifier in the view and the transaction commit identifiers indexed by the storage addresses respectively recorded in different versions in the version chain of the target data object, searching the visible version of the second transaction from the version chain;

[0014] The storage address corresponds to a storage space in a persistent storage medium, the storage space corresponds to a write transaction and is applied for when the write transaction is started, and the transaction commit identifier is generated and stored in the storage space when the transaction is committed.

[0015] In a third aspect, an embodiment of the present application provides a computer system, including a processing component and a storage component; the storage component includes a memory and a persistent storage medium;

[0016] The storage component stores one or more computer instructions; the one or more computer instructions are used to be called and executed by the processing component to implement the transaction processing method as described in the first aspect above, or to implement the transaction processing method as described in the second aspect above.

[0017] In a fourth aspect, a computer storage medium is provided in an embodiment of the present application, wherein a computer program is stored. When the computer program is executed by a computer, the transaction processing method as described in the first aspect above is implemented, or the transaction processing method as described in the second aspect above is implemented.

[0018] In an embodiment of the present application, when a first transaction is started, a storage space corresponding to the first transaction is requested from a persistent storage medium; the storage address of the storage space is recorded for at least one data object updated by the first transaction; when the first transaction is committed, a transaction commit identifier of the first transaction is generated; and the transaction commit identifier is stored in the storage space. For a second transaction that performs data query, a view of the second transaction is constructed based on the most recently generated transaction commit identifier; the visible version of the second transaction is searched from the version chain according to the transaction commit identifier in the view and the transaction commit identifier indexed by the storage address recorded by different versions in the version chain of the target data object; the embodiment of the present application can quickly and efficiently search for visible versions through the transaction commit identifier stored in the persistent storage medium, without holding the lock for a long time, unbinding the conflict in the use of read-write locks, and without maintaining complex memory data structures, thereby improving resource utilization and processing performance.

[0019] These and other aspects of the present application will become more clearly understood in the description of the following embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0021] Figure 1 A schematic diagram of a system architecture in which the technical solution of an embodiment of the present application is applied is shown;

[0022] Figure 2 A flowchart of an embodiment of a transaction processing method provided by the present application is shown;

[0023] Figure 3 A flowchart of another embodiment of a transaction processing method provided by the present application is shown;

[0024] Figure 4 A schematic diagram of a transaction processing process in an actual application of an embodiment of the present application is shown;

[0025] Figure 5 A schematic diagram showing the structure of an embodiment of a transaction processing device provided by the present application is shown;

[0026] Figure 6 A schematic diagram showing the structure of another embodiment of a transaction processing device provided by the present application;

[0027] Figure 7A schematic diagram of the structure of an embodiment of a computer system provided by the present application is shown. DETAILED DESCRIPTION

[0028] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application.

[0029] In some of the processes described in the specification and claims of this application and the above-mentioned figures, multiple operations that appear in a specific order are included, but it should be clearly understood that these operations may not be executed in the order in which they appear in this article or executed in parallel. The serial numbers of the operations, such as 101, 102, etc., are only used to distinguish between different operations, and the serial numbers themselves do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel. It should be noted that the descriptions of "first", "second", etc. in this article are used to distinguish different messages, devices, modules, etc., do not represent the order of precedence, and do not limit the "first" and "second" to be different types.

[0030] The technical solution of the embodiment of the present application is applied to a database system for processing transactions. The technical solution of the embodiment of the present application can be executed by a transaction system in the database system, and the transaction system can refer to a transaction processing engine in the database system.

[0031] In order to facilitate understanding of the technical solution of this application, the following is an explanation of the technical terms that may be involved in this application:

[0032] Transaction: A set of operations in a database system used to access and possibly manipulate data objects. A transaction may include at least one operation, which may include a query operation and / or an update operation, and an update operation may include inserting, deleting, or replacing, etc. In a relational database, a transaction may include an SQL statement, a group of SQL statements, etc. Transactions have the characteristics of atomicity, consistency, isolation, and persistence. Transactions usually start with a start command (BEGIN or START) and end with a commit command (COMMIT) or a rollback command (ROLLBACK).

[0033] Data object: The data stored in the database provided by the database system can refer to a data record in the database table, that is, the row data of the database table.

[0034] Undo log: In the multi-version concurrency control mechanism, when a transaction updates a data object, the old version of the data object will be stored in the undo log, and then the data object will be updated to obtain a new version, and the new version will point to the old version through the undo pointer. For example, if the data object is a data record, a undo pointer field will be set in the data object to point to the previous version of the data object.

[0035] Version chain: A version chain consisting of the latest version of a data object and the old version in the rollback log.

[0036] Transaction ID: Assigned when a transaction is started, used to uniquely identify the transaction and represent the order in which the transaction is started.

[0037] Transaction commit identifier: assigned when a transaction is committed, used to represent the transaction commit order.

[0038] Persistent storage medium: a storage medium used to permanently store data, such as a disk.

[0039] Memory: Internal storage used to temporarily store computing data in the processor.

[0040] As described in the background technology, in the current multi-version concurrency control mechanism, it is necessary to maintain two memory data structures in the memory, and lock the two memory data structures when the write transaction performs an update operation and the read transaction performs a read operation to achieve the purpose of isolation. The specific implementation method is to search for and access the visible version from the different versions corresponding to the target data object requested for query in combination with the transaction identifiers recorded in the different versions based on the minimum transaction identifier and the maximum transaction identifier constructed by the read transaction: for the current search version, if the transaction identifier recorded in the current search version is less than the minimum transaction identifier, then the version is visible to the read transaction; if the transaction identifier of the current search version is greater than the maximum transaction identifier, then the version is invisible to the read transaction, and it is necessary to continue to search for the previous version; if the current search version is included in the currently surviving transaction identifier set corresponding to the view, then the version is invisible to the read transaction, and it is necessary to continue to search for the previous version. However, this implementation method has the problem of lock contention, especially in mixed read-write scenarios. A large number of write transactions will lead to a larger set of active transactions, which means that the view construction needs to be held for a longer time to perform the copy operation, which makes the lock contention problem serious and causes the processor to spend most of its time in useless waiting. In particular, when the transaction system is deployed in a single-machine multi-core scenario, it cannot fully utilize the processor resources, resulting in a waste of resources that are not fully utilized, resulting in a decrease in processing performance.

[0041] In order to improve the processing performance, the inventor has proposed the technical solution of the present application after a series of studies. In the embodiment of the present application, when the first transaction is started, the storage space corresponding to the first transaction is first applied from the persistent storage medium; the storage address of the storage space is recorded for at least one data object updated by the first transaction; when the first transaction is committed, the transaction commit identifier of the first transaction is generated; and the transaction commit identifier is stored in the storage space. For the second transaction that reads data, a view of the second transaction is constructed based on the most recently generated transaction commit identifier; according to the transaction commit identifier in the view and the transaction commit identifier indexed by the storage address recorded by different versions in the version chain of the target data object, the visible version of the second transaction is searched from the version chain; the embodiment of the present application uses the transaction commit identifier stored in the persistent storage medium to search for the visible version. Since whether a transaction can access the version updated by another transaction depends on whether the other transaction has been committed when the view is constructed by one transaction, the visible version can be quickly and efficiently searched through the transaction commit identifier, without holding the lock in the memory for a long time, unbinding the conflict of using the read-write pair lock, and without maintaining a complex memory data structure, reducing the processor waiting time, improving resource utilization, and improving processing performance.

[0042] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of this application.

[0043] Figure 1 The technical solution of the embodiment of the present application can be applied to an exemplary system architecture diagram, which can be composed of a request end 101 and a transaction system 102. The user can submit a transaction to the transaction system 102 through the request end 101; the transaction system 102 can start a transaction based on the transaction submitted by the request end 101, execute a series of operations included in the transaction on the database 103, and commit the transaction after successful execution or roll back the transaction after failed execution. The transaction system 102 can receive transactions sent by multiple request ends 101, so that there are multiple transactions executing concurrently at the same time. In addition, after the transaction system 102 is executed, the execution result can be fed back to the request end 101.

[0044] The requesting end 101 may be a client deployed in an electronic device, and the electronic device may be, for example, one or more of a smart phone, a tablet computer, and a portable computer, and may also be a desktop computer, etc. For ease of understanding, Figure 1 The client is mainly represented by a device image.

[0045] The transaction system 102 can be deployed as software in a computer system composed of a storage component and a processing component, and the computer system can be a single physical machine, or a server of a distributed system, or a server combined with blockchain, or a cloud server, or an intelligent cloud computing server or intelligent cloud host with artificial intelligence technology. The processing component can include one or more processors, and in an actual application, it can be composed of a multi-core processor.

[0046] The database 103 may be a local database or a cloud database, etc., which is not limited in the present application. The database 103 and the transaction system 102 may be deployed in the same physical machine, and the database 103 may be deployed in the persistent storage medium of the physical machine, etc.

[0047] The database of the embodiment of the present application may refer to a relational database (RDS, Relational Database Service), such as MySQL, and the transaction system may be, for example, a core component for performing transaction processing in the database, for example, it may be a core component in the storage engine InnoDB of MySQL, etc.

[0048] The implementation details of the technical solution of the embodiment of the present application are elaborated in detail below.

[0049] Figure 2 This is a flowchart of an embodiment of a transaction processing method provided in an embodiment of the present application. The technical solution of this embodiment is executed by a transaction system. The method may include the following steps:

[0050] 201: When a first transaction is started, a storage space corresponding to the first transaction is requested from a persistent storage medium.

[0051] Among them, the first transaction can refer to any write transaction. The write transaction in the embodiment of the present application refers to a transaction including an update operation. Of course, the write transaction can also include a query operation, etc.

[0052] The operations included in the first transaction are executed serially, and when the first transaction is started and the first update operation is executed, the storage space corresponding to the first transaction is requested from the persistent storage medium.

[0053] Optionally, a specific storage structure can be pre-configured in the persistent storage medium. When the first transaction is started, the storage space corresponding to the first transaction is requested from the storage structure configured in the persistent storage medium, so that the storage address of the storage space can be obtained. The storage address can be represented by a storage space identifier and a file offset, etc. The present application does not specifically limit its implementation form. Each write transaction can be executed according to the technical solution of the present application to correspond to a storage space in the persistent storage medium.

[0054] The first transaction may be initiated after receiving a transaction processing request triggered by a requesting end.

[0055] 202: Record a storage address of a storage space for at least one data object updated by the first transaction.

[0056] The first transaction may include at least one update operation, and the at least one update operation may be used to update at least one data object, such as inserting, deleting, or replacing, etc. The at least one update operation is executed serially according to the transaction definition order, etc.

[0057] For each data object updated by the update operation, the old version of the data object may be first saved in the rollback log, and then the data object may be updated to generate the latest version.

[0058] In practical applications, a data object may refer to, for example, a data record in a database table, i.e., row data. In an embodiment of the present application, an address field may be added to the data record to store a storage address, and the address field may refer to an implicit field that is invisible to the user.

[0059] 203: When the first transaction is committed, generate a transaction commit identifier of the first transaction.

[0060] 204: Store the transaction commit identifier of the first transaction in the storage space.

[0061] After the first transaction is fully executed successfully, commit can be triggered. When the first transaction is committed, in an embodiment of the present application, a transaction commit identifier is generated for the first transaction. The transaction commit identifier can indicate the transaction commit time of the first transaction to determine the transaction commit order of the first transaction and other transactions.

[0062] Among them, the transaction commit identifier can be generated by increasing the first specified value each time starting from the first initial value according to the increasing principle. Optionally, the first generator can be configured, and when the first transaction is committed, the first generator is requested to generate the transaction commit identifier, that is, the first generator specifically generates the transaction commit identifier by increasing the first specified value each time starting from the first initial value according to the increasing principle. The first initial value can be 1, for example, and the first specified value can be 1, etc. Of course, other principles, such as the decreasing principle, etc., can also be used to produce the transaction commit identifier, and this application does not specifically limit this.

[0063] As another optional manner, the transaction commit time of the first transaction may also be used as the transaction commit identifier.

[0064] When the first transaction is committed, a lock may be held to generate a transaction commit identifier for the first transaction. For example, the first generator may be locked so that other transactions cannot access the first generator to ensure isolation.

[0065] The generated transaction commit identifier is written into the storage space. Thus, the storage space can be used to query the transaction commit identifier of the first transaction. Based on the transaction commit identifier of the first transaction, the visible version of the target data object requested by the second transaction can be found. Specifically, the transaction commit identifier of the first transaction can be combined with the transaction commit identifier in the view constructed for the second transaction to find the visible version of the target data object requested by the second transaction.

[0066] The target data object may be any object requested by the second transaction, and it may be any object updated by the first transaction. The view of the second transaction is constructed based on the most recently generated transaction commit identifier. Since the transaction commit identifier can indicate the transaction commit time and the transaction commit order, it can be determined whether the first transaction has been committed before the second transaction generates the view by combining the transaction commit identifier of the first transaction and the transaction commit identifier in the view, thereby determining whether the version of the target data object updated by the first transaction is visible to the second transaction, etc. If the first transaction has been committed, the version is visible to the second transaction and is a visible version, otherwise it is an invisible version, and the previous version linked to the version can be searched, specifically, the historical version pointed to by the rollback segment pointer of the invisible version record can be searched. In the case where the transaction commit identifier is generated using the incremental principle, it can be determined that the version of the target data object updated by the first transaction is a visible version when the transaction commit identifier in the view is greater than or equal to the transaction commit identifier of the first transaction, otherwise it is an invisible version. The version chain is traced back in non-increasing order. After obtaining the visible version, the search can be terminated and the visible version can be returned. For example, the version chain includes V0, V1, V2 and V3 versions. The transaction commit identifier of V0 is 10, the transaction commit identifier of V1 is 20, the transaction commit identifier of V2 is 20, the transaction commit identifier of V3 is 30, and the transaction commit identifier in the view is 21. The search starts from version V3, and the search is terminated after the final visible version is determined to be version V2, and version V2 is returned. The second transaction accesses version V2.

[0067] In addition, if the query obtains that the storage space still records the transaction commit identifier of the first transaction, it indicates that the first transaction may not have been committed yet, and the version of the target data object updated by the first transaction can be directly determined as an invisible version.

[0068] In this embodiment, by storing transaction commit identifiers in a persistent storage medium, visible versions can be found quickly and efficiently without holding locks in the memory for a long time, thus unbinding conflicts in the use of read-write locks and eliminating the need to maintain complex memory data structures, thereby reducing processor waiting time and improving resource utilization and processing performance.

[0069] In some embodiments, the method may further include:

[0070] When a first transaction is started, a transaction identifier of the first transaction is generated; and the transaction identifier of the first transaction is recorded for at least one data object respectively.

[0071] In the embodiment of the present application, when the first transaction is started, a transaction identifier may also be generated and recorded in the data object updated by the first transaction.

[0072] Among them, the transaction identifier of the version record of the target data object updated by the first transaction is used to determine that the version is a visible version when it is consistent with the transaction identifier of the second transaction. Otherwise, the transaction commit identifier of the first transaction is searched from the storage space based on the storage address of the version record. If the transaction identifier of the version record is consistent with the transaction identifier of the second transaction, it indicates that the second transaction and the first transaction are the same transaction, and the second transaction is accessing the data object updated by itself. Since multiple operations of the transaction are executed serially, there is no conflict problem, so this version can be directly used as a visible version; otherwise, in the case of inconsistency, the transaction commit identifier of the first transaction is searched from the index storage space based on the storage address of the version record, and then combined with the transaction commit identifier of the first transaction to determine whether the version is a visible version, etc.

[0073] The second generator may be used to generate a transaction identifier, which is used to uniquely identify a transaction and represents the order in which the transaction is started. For example, the transaction identifier may be generated based on an incremental principle, starting from the second initial value, and increasing the second specified value each time, etc. This application does not specifically limit this.

[0074] To further improve processing efficiency, as an optional implementation, when the first transaction is committed, after generating a transaction commit identifier for the first transaction, the method may further include: recording the transaction commit identifier of the first transaction for at least some of the data objects in at least one data object.

[0075] In one implementation, the at least part of the data objects may be all the data objects. In another implementation, when there are many data objects updated by the first request, recording the transaction commit identifier of the first transaction for each data object will seriously affect the transaction commit performance. Therefore, the at least part of the data objects may be a specified number of data objects selected from the at least one data object, which may be randomly selected or selected in the order of update. The specified number may be dynamically set in combination with the device performance in actual applications.

[0076] As another optional implementation, the method may further include: when performing a query operation on the current search version of any data object, recording a transaction commit identifier obtained by querying the storage space for the current search version of the data object. That is, when performing a query operation on any data object, the transaction commit identifier obtained by querying is recorded in the data object.

[0077] Optionally, when performing a query operation on the current search version of any data object, you can first check whether the transaction commit identifier is recorded in the data object. If so, use it as the transaction commit identifier of the first transaction. Otherwise, based on the storage address recorded in the current search version, query the transaction commit identifier from the storage space, and record the transaction commit identifier obtained from the storage space query to the current search version of the data object.

[0078] Wherein, when the data object is a data record, a transaction commit identifier field may be added to the data record to store the transaction commit identifier. The transaction commit identifier field may be an implicit field.

[0079] In addition, after performing a query operation on the current search version of any data object and obtaining a transaction commit identifier from the storage space query, the corresponding relationship between the transaction commit identifier and the transaction identifier of the write transaction that updates the current search version can also be saved in the memory.

[0080] Therefore, when performing a query operation on the current search version of any data object, you can first check whether the transaction commit identifier is recorded in the data object. Otherwise, based on the transaction identifier recorded in the current search version, you can check from the memory whether there is a transaction commit identifier corresponding to the write transaction that updates the current search version. If so, you can determine the visible version based on the transaction commit identifier stored in the memory and the transaction commit identifier in the view. In addition, you can also record the transaction commit identifier in the memory to the data object. If not, based on the storage address recorded in the current search version, search for the transaction commit identifier from the storage space, and record the transaction commit identifier obtained from the storage space in the current search version of the data object.

[0081] That is, when the transaction commit identifier is not recorded in the version of the data object updated by the transaction and the transaction commit identifier corresponding to the transaction is not saved in the memory, the transaction commit identifier is queried from the storage space.

[0082] Optionally, in order to improve processing performance, it may be determined whether to record the transaction commit identifier obtained from the storage space query for the current search version of the data object according to database pressure and processing resource usage.

[0083] In addition, in order to avoid unlimited expansion of the storage structure in the persistent storage medium, the storage structure can also support reuse, so the storage space applied for the first transaction from the persistent storage medium can be the storage space selected according to the reuse mechanism, and can be the storage space selected for the first transaction according to the reuse mechanism when there is no free space in the storage structure. The reuse mechanism can be, for example, the earliest used storage space in the storage structure, or the storage space that has not been accessed within a certain period of time, or the storage space with a total access count lower than a predetermined count, etc.

[0084] When the storage space is reused, the original data stored in the storage space can also be transferred to other places to facilitate searching, etc. Therefore, in some embodiments, the method can also include:

[0085] The transaction identifier of the first transaction is stored in the storage space, wherein the transaction identifier and the transaction commit identifier constitute a record data;

[0086] When the storage space is reused, the original record data stored in the storage space is transferred and a link relationship between the storage space and the original record data is established; the link relationship is used for the target record data corresponding to the transaction identifier of the first transaction to obtain the transaction commit identifier of the first transaction.

[0087] In one implementation, the storage structure may be a linked list structure, and the storage space may be a node in the linked list structure. When the storage space is reused, the original record data may be transferred to other nodes. Therefore, the storage space may be reused based on an application event for the storage space, or may be reused based on a data transfer event, etc. The storage space in the storage structure may be linked to the storage space storing its original record data through a pointer, etc., so that based on the link relationship formed by the pointers of different storage spaces, the target record data corresponding to the transaction identifier of the first transaction may be searched to obtain the transaction commit identifier of the first transaction in the target record data.

[0088] In addition, in order to improve processing efficiency, in some embodiments, the method may further include:

[0089] When the storage structure meets the clearing condition, the record data corresponding to the earliest generated transaction commit identifier in the storage structure is cleared.

[0090] Since the record data corresponding to the first transaction may have been cleared, it may not be possible to query the transaction commit identifier of the first transaction from the storage structure. In order to ensure that the visible version is obtained normally, the transaction condition identifier in the most recently cleared record data can be used as the transaction commit identifier of the first transaction when the transaction commit identifier of the first transaction cannot be queried from the storage structure. That is, the most recently cleared record data can be used as a pseudo transaction commit identifier of the first transaction to find the visible version.

[0091] The clearing condition may refer to, for example, reaching a scheduled time or a specified time, or insufficient storage space in the storage structure, that is, the record data corresponding to the earliest generated transaction submission identifier in the storage structure may be cleared at a scheduled time or at a specified time or when the storage structure is insufficient.

[0092] In addition, when querying the storage space for the target data object, the first transaction may not be committed, the transaction commit identifier has not been generated, and the transaction commit identifier has not been stored in the storage space. At this time, it can be determined that the current version is an invisible version.

[0093] In addition, in some embodiments, transaction status information of the first transaction can also be stored in the storage space based on the real-time transaction status of the first transaction. The transaction status information may include, for example, a commit status and an active status, etc., wherein the active status may indicate that the transaction is in the initial stage or has not been committed, etc., and the commit status indicates that the transaction has been terminated, etc.

[0094] Therefore, when the storage space is queried for the version of the target data object updated by the first transaction, the transaction status information is checked for the first time. If the transaction status information is in an active state, the transaction commit identifier is not generated at this time, and the version is an invisible version; if the transaction status information is in a committed state, the transaction commit identifier is stored in the storage space, and then it can be determined whether the version is a visible version based on the transaction commit identifier.

[0095] In the case where the storage space can be reused or cleared, you can first check whether the transaction identifier stored in the storage space is consistent with the transaction identifier recorded in the version, and then check the transaction status information if they are consistent.

[0096] The above corresponding embodiments mainly introduce the technical solution of the present application from the perspective of data update. The following mainly introduces the technical solution of the present application from the perspective of data query. Figure 3 FIG. 1 is a flowchart of another embodiment of a transaction processing method provided by an embodiment of the present application. The method may include the following steps:

[0097] 301: Build a view of the second transaction based on the most recently generated transaction commit identifier.

[0098] The second transaction may refer to a transaction including a query operation, and in an optional manner, may refer to a read-only transaction including only a query operation but not an update operation. Of course, it may also refer to a transaction including both a query operation and an update operation.

[0099] Based on different isolation level requirements, based on the most recently generated transaction commit identifier, building the view of the second transaction can be that when the second transaction executes a query operation, the most recently generated transaction commit identifier is obtained to build the view of the second transaction; or, when the second transaction is started, the most recently generated transaction commit identifier is obtained to build the view of the second transaction.

[0100] When the transaction commit identifier is generated by the first generator, the view of the second transaction is constructed based on the transaction commit identifier most recently generated by the first generator.

[0101] 302: According to the transaction commit identifier in the view and the transaction commit identifiers indexed by storage addresses respectively recorded in different versions in the version chain of the target data object, search the version chain for a visible version of the second transaction.

[0102] The target data object may be any object requested to be queried by the query operation in the second transaction. The second transaction may execute multiple query operations, and each query operation may be executed in the manner of step 302 to determine the visible version of this query operation. According to the above description, a view may be constructed separately when each query operation is executed, or each query operation may use the view constructed when the second transaction is started.

[0103] The version chain of the target data object consists of the latest version and historical versions of the target data object. The historical version is stored in the rollback log, and different versions in the version chain are linked by rollback segment pointers. The corresponding previous version can be found according to the rollback segment pointer recorded in each version.

[0104] The storage address corresponds to the storage space in the persistent storage medium, the storage space corresponds to a write transaction and is applied for when the write transaction is started, and the transaction commit identifier is generated when the transaction is committed. The specific implementation of the storage space and transaction commit identifier can be found in Figure 2 As described in the illustrated embodiment, no further details will be given here.

[0105] Wherein, when the transaction commit identifier is generated by the first generator according to the incremental principle, the visible version of the second transaction can be searched from the version chain according to the transaction commit identifier in the view and the transaction commit identifier indexed by the storage address recorded in the version chain of the target data object. The visible version of the second transaction can be searched from the version chain according to the judgment result of whether the transaction commit identifier in the view is greater than or equal to the transaction commit identifier indexed by the storage address recorded in the version chain of the target data object. If the transaction commit identifier corresponding to any version is less than or equal to the transaction commit identifier in the view, the version is the visible version, otherwise it is the invisible version, and the previous version linked to the version is searched.

[0106] In this embodiment, by storing the transaction commit identifier in a persistent storage medium, the visible version of the second transaction can be quickly and efficiently found. The second transaction does not need to hold the lock in the memory for a long time, which resolves the conflict between the read and write locks. There is no need to maintain a complex memory data structure, which reduces the processor waiting time, thereby improving resource utilization and processing performance.

[0107] In some embodiments, searching the visible version of the second transaction from the version chain according to the transaction commit identifier in the view and the transaction commit identifier indexed by the storage addresses respectively recorded by different versions in the version chain of the target data object may include:

[0108] Determine a version chain consisting of the latest version of the target data object and the historical version of the target data object stored in the rollback log;

[0109] Starting from the latest version in the version chain, for any version, perform the following visibility judgment operation, where the visibility judgment operation includes:

[0110] Querying the transaction commit identifier of the third transaction that updates the version from the storage space indexed by the storage address of the version record;

[0111] According to the transaction commit identifier in the view and the transaction commit identifier of the third transaction, it is determined whether the version is a visible version of the second transaction.

[0112] When a visible version is found in the version chain or no visible version exists in the version chain, the visibility determination operation can be terminated.

[0113] Among them, if the third transaction that updates the version has not been committed, the transaction commit identifier has not been generated, and the transaction commit identifier has not been stored in the storage space indexed by the storage address of the version record. At this time, the version can be directly determined to be an invisible version, that is, if the transaction commit identifier is not recorded in the storage space indexed by the storage address of the version record, the version is determined to be an invisible version.

[0114] In addition, in some embodiments, transaction status information can also be stored in the storage space. Therefore, the transaction status information can be first queried from the storage space indexed by the storage address of the version record. If it is in an active state, it can be directly determined that the version is an invisible version. Otherwise, if it is in an uncommitted state, the transaction commit identifier can be queried.

[0115] For the convenience of description, the transaction that updates this version is named the third transaction. The third transaction is also a write transaction. For details about the transaction processing operations performed after the third transaction is started, see Figure 2 As described in the illustrated embodiment, the transaction processing operation is the same as that performed after the first transaction is initiated, and will not be described in detail here. In a possible actual scenario, the third transaction may be the first transaction.

[0116] When the transaction commit identifier is generated according to the incremental principle, the transaction commit identifier in the view may be greater than or equal to the transaction commit identifier of the third transaction, and the version is determined to be a visible version of the second transaction. Then, a query operation can be performed on the visible version, and a query result can be generated. The query result can be fed back to the request end after the second transaction is committed.

[0117] If the transaction commit identifier in the view is less than the transaction commit identifier of the third transaction, the version is determined to be an invisible version, and the previous version linked to the version is searched, and the visibility judgment operation is continued for the version.

[0118] As described in the above corresponding embodiments, after the write transaction is started, a transaction identifier of the write transaction can be generated and recorded in the data object updated by the write transaction. Therefore, different versions of the target data object also record transaction identifiers respectively; in some embodiments, according to the transaction commit identifier stored in the storage space indexed by the storage address recorded in the version, determining the transaction commit identifier of the third transaction that updates the version may include:

[0119] When the transaction identifier of the version record is consistent with the transaction identifier of the second transaction, the version is determined to be the visible version of the second transaction. Otherwise, the transaction commit identifier of the third transaction that updates the version is determined based on the transaction commit identifier stored in the storage space indexed by the storage address of the version record. The transaction identifier of the version record means the transaction identifier of the third transaction that updates the version. If it is consistent with the transaction identifier of the second transaction, it indicates that the second transaction queries the version of the data object updated by itself. Since the operations of the second transaction are executed serially, there is no conflict problem. Therefore, the version is directly used as the visible version of the second transaction.

[0120] In some embodiments, the transaction identifier corresponding to each write transaction may also be stored in the storage space corresponding to the write transaction. A record data is composed of the transaction identifier and the corresponding transaction commit identifier, and the storage space stores the record data. When the storage space supports multiplexing, and when it is reused, the original record data is transferred and a link relationship between the storage space and the original record data is established. Among them, the storage space can be applied from the storage structure of the persistent storage medium, and the storage structure can be a linked list structure. The storage space is a node in the linked list structure, and the original record data can be transferred from one node to another node.

[0121] The determining, based on the transaction commit identifier stored in the storage space indexed by the storage address of the version record, the transaction commit identifier of the third transaction that updates the version may include:

[0122] When the transaction identifier stored in the storage space indexed by the storage address of the version record is consistent with the transaction identifier of the version record, determining the transaction commit identifier of the third transaction that updates the version according to the transaction commit identifier stored in the storage space indexed by the storage address of the version record;

[0123] When the transaction identifier stored in the storage space is inconsistent with the transaction identifier recorded in the version, the transaction commit identifier corresponding to the third transaction is searched according to the link relationship between different storage spaces.

[0124] In some embodiments, transaction status information may also be stored in the storage space. When the transaction identifier stored in the storage space indexed by the storage address of the version record is consistent with the transaction identifier of the version record, the transaction commit identifier stored in the storage space is used as the transaction commit identifier of the third transaction that updates the version. The transaction commit identifier may be:

[0125] When the transaction identifier stored in the storage space indexed by the storage address of the version record is consistent with the transaction identifier of the version record, querying the transaction status information of the third transaction that updates the version from the storage space;

[0126] If the transaction status information is a commit status, using the transaction commit identifier stored in the storage space as a transaction commit identifier of a third transaction that updates the version;

[0127] If the transaction status information is in an active state, it is determined that the version is an invisible version.

[0128] In order to prevent the storage result from expanding infinitely, the data stored in the storage space in the storage structure will be cleared according to the clearing mechanism, for example, the record data corresponding to the earliest generated transaction commit identifier in the storage structure will be cleared.

[0129] Therefore, in some embodiments, if the transaction identifier stored in the storage space indexed by the storage address of the version record is inconsistent with the transaction identifier of the version record, the transaction commit identifier in the most recently cleared record data may be used as the transaction commit identifier of the third transaction.

[0130] In addition, when the storage space supports reuse, the original record data of the storage space may have been transferred, and the transaction commit identifier corresponding to the third transaction can be found through the link relationship. If the transaction commit identifier of the third transaction cannot be found, the transaction commit identifier in the most recently cleared record data can be used as the transaction commit identifier of the third transaction.

[0131] In addition, in some embodiments, since the second transaction may perform multiple query operations, the transaction commit identifier obtained by the query in the first query operation can be saved in the memory corresponding to the transaction identifier of the third transaction. Therefore, according to the transaction commit identifier stored in the storage space indexed by the storage address of the version record, determining the transaction commit identifier of the third transaction that updates the version may include:

[0132] According to the transaction identifier of the third transaction recorded in the version, searching in the memory whether the corresponding transaction commit identifier is saved;

[0133] If yes, use the transaction commit identifier saved in the memory as the transaction commit identifier of the third transaction;

[0134] If not, the transaction commit identifier of the third transaction is queried from the storage space indexed by the storage address of the version record, and the transaction identifier of the third transaction is saved in the memory.

[0135] Of course, you can first determine whether the query operation corresponding to the version is the first query operation of the second transaction. If not, then search the memory to see whether the corresponding transaction commit identifier is saved. If so, you can directly execute the storage space indexed by the storage address of the version record, query the transaction commit identifier of the third transaction, and save the corresponding transaction identifier of the third transaction in the memory.

[0136] In some embodiments, while using the transaction commit identifier stored in the memory as the transaction commit identifier of the third transaction, the transaction commit identifier stored in the memory may also be recorded in the version;

[0137] After querying the transaction commit identifier of the third transaction from the storage space indexed by the storage address recorded in the version, the transaction commit identifier stored in the storage space may also be recorded in the version.

[0138] Therefore, according to the transaction identifier of the third transaction in the version record, searching from the memory whether the transaction commit identifier of the third transaction is saved may include:

[0139] Determine whether the transaction commit identifier of the third transaction is recorded in the version; if not, search the memory for the corresponding transaction commit identifier according to the transaction identifier of the third transaction recorded in the version;

[0140] In order to facilitate further understanding, the following will be combined Figure 4 The transaction processing process diagram shown explains the technical solution of the present application.

[0141] When the first transaction is started or the first update operation is performed, the second generator can be locked and the transaction identifier Trx ID can be obtained from the second generator. The second generator can generate Trx ID according to the incremental principle and then release the lock. At the same time, a storage space is applied for the first transaction from the storage structure configured by the persistent storage medium, and the storage address TSA of the storage space is obtained.

[0142] The data object of a transaction operation may refer to a data record. In the embodiment of the present application, implicit fields such as a transaction identification field, an address field, a transaction commit identification field, and a rollback pointer field may be added to the data record.

[0143] When the first transaction updates a data record A, it first saves the old version of the data record A to the rollback log, then updates the user data in the data record A, adds the transaction identifier TrxID to the transaction identifier field, and adds the rollback segment pointer Rollptr pointing to the old version to the rollback pointer field. Since the first transaction has not been committed yet, the transaction commit identifier field can be a null value.

[0144] When the first transaction is committed, the first generator can be locked, and the transaction commit identifier TCN can be obtained from the first generator. The first generator can generate TCN according to the incremental principle, and then the lock can be released. The generated TCN and transaction Trx ID are filled in the storage space of the first transaction.

[0145] In addition, the storage space may also record the transaction status information of the first transaction according to the real-time execution status of the first transaction. Of course, the storage space may also store other transaction-related information in combination with actual conditions, and this application does not specifically limit this.

[0146] The transaction commit identifier field in data record A can be filled with the generated transaction commit identifier TCN when the first transaction is committed. Of course, it can also be filled in when querying the data record A, which will be introduced below.

[0147] Among them, a linked list structure can be used in actual applications of the storage structure. The storage space in the storage structure supports reuse. When a storage space is reused, its original record data can be transferred to other storage spaces, and a link relationship between storage spaces can be established through pointers.

[0148] When the second transaction is started or the first query operation is executed, the second generator is locked, and a view is built based on the TCN most recently generated by the second generator.

[0149] For the current query operation of the second transaction, for the convenience of illustration, it is assumed that the data record A is requested for query. It should be noted that in actual applications, the second transaction may query any data record. The visibility judgment operation is performed starting from the latest version of data record A:

[0150] For a certain version, first check whether the Trx ID recorded in the version is the same as the Trx ID of the second transaction. If they are the same, it means that the second transaction requests to query the version updated by itself, and this version is the visible version.

[0151] If the Trx ID recorded in the version is different from the Trx ID of the second transaction, or the TrxID of the second transaction is not generated, then check whether the TCN is recorded in the version. The TCN recorded in the version is the TCN of the third transaction that updates the data record. The third transaction may be the same as or different from the first transaction. If the version records the TCN of the third transaction, the TCN recorded in the version can be directly compared with the TCN in the view. If the TCN in the view is greater than or equal to the TCN recorded in the version, then the version is a visible version, otherwise it is an invisible version.

[0152] If TCN is not recorded in the version, the corresponding storage space can be queried from the storage structure according to the TSA recorded in the version. The Trx ID of the storage space can be checked first to see if it is consistent with the Trx ID recorded in the version. If not, it indicates that the storage space has been reused. The original record data corresponding to the Trx ID recorded in the version can be found through the pointer, and the TCN of the third transaction can be obtained from the original record data for judgment, and the TCN of the third transaction can be backfilled into the transaction commit identification field of the version. If the original record data is still not found, the storage structure will also be cleared according to the clearing conditions, and the record data corresponding to the earliest generated transaction commit identification will be cleared; therefore, at this time, the TCN in the most recently cleared record data can also be used as the TCN of the third transaction to compare with the view TCN, and backfilled into the transaction commit identification field of the version.

[0153] If they are consistent, you can first check the transaction status information recorded in the storage space. If it is active, it means that the third transaction has not been committed. At this time, the version is invisible to the second transaction and is an invisible version. If it is committed, check the TCN of the third transaction in the storage space, and then compare the TCN of the third transaction with the TCN in the view. If the TCN in the view is greater than or equal to the TCN of the third transaction, then the version is a visible version, otherwise it is an invisible version. At this time, you can also fill the TCN obtained from the storage space back into the transaction commit identification field of the version.

[0154] Of course, if the query operation corresponding to the version is the first query operation of the second transaction, the TCN obtained from the storage structure and the Trx ID of the third transaction can also be saved in the memory. Therefore, in subsequent query operations, if TCN is not recorded in any version, you can first search from the memory based on the Trx ID recorded in the version to see if there is a corresponding TCN, etc. If it exists, there is no need to obtain it from the storage structure. At this time, the TCN found in the memory can also be filled back into the transaction submission identification field of the version.

[0155] For a visible version, you can terminate the search and perform the corresponding query operation on the visible version to obtain the query result. For an invisible version, you can find the previous version based on the rollback segment pointer of the version record and continue to perform visibility judgment until the visible version is found.

[0156] When the second transaction is committed, the query result generated by the second transaction can be fed back to the requesting end, etc.

[0157] Figure 5 A flowchart of an embodiment of a transaction processing device provided in an embodiment of the present application, the device may include:

[0158] An application module 501 is used to apply for storage space corresponding to the first transaction from a persistent storage medium when the first transaction is started;

[0159] A recording module 502, configured to record storage addresses of storage spaces for at least one data object updated by the first transaction;

[0160] A generating module 503, configured to generate a transaction commit identifier of the first transaction when the first transaction is committed;

[0161] The storage module 504 is used to store the transaction commit identifier in the storage space; wherein the storage space is used to query the transaction commit identifier of the first transaction, and the transaction commit identifier of the first transaction is used to find the visible version of the target data object queried by the second transaction request.

[0162] In some embodiments, the generating module is further configured to generate a transaction identifier of the first transaction when the first transaction is initiated;

[0163] The recording module is also used to record transaction identifiers for at least one data object respectively; wherein the transaction identifier of the version record of the target data object updated by the first transaction is used to determine that the version is a visible version when it is consistent with the transaction identifier of the second transaction; otherwise, based on the storage address of the version record, the transaction commit identifier of the first transaction is queried from the storage space.

[0164] In some embodiments, the recording module is also used to record the transaction commit identifier of the first transaction for at least some of the at least one data object; or, when a query operation is performed on the current search version of any data object, record the transaction commit identifier obtained from the storage space query for the current search version of the data object.

[0165] In some embodiments, the application module may be specifically used to apply for a storage space corresponding to the first transaction from a storage structure configured by a persistent storage medium when the first transaction is started, and obtain a storage address of the storage space;

[0166] Wherein, the storage structure supports reuse, and the device may further include:

[0167] A multiplexing module is used to store a transaction identifier in a storage space, and a transaction identifier and a transaction commit identifier constitute a record data; when the storage space is reused, the original record data stored in the storage space is transferred and a link relationship between the storage space and the original record data is established; the link relationship is used to find the target record data corresponding to the transaction identifier of the first transaction to obtain the transaction commit identifier of the first transaction.

[0168] In some embodiments, the apparatus may further include:

[0169] A clearing module is used to clear the record data corresponding to the earliest generated transaction commit identifier in the storage structure when the storage structure meets the clearing condition; wherein the transaction commit identifier in the most recently cleared record data is used as the transaction commit identifier of the first transaction when the transaction commit identifier of the first transaction cannot be queried from the storage structure.

[0170] In some embodiments, the storage module is also used to store transaction status information of the first transaction in the storage space; the transaction status information is used to determine, when querying the storage space for the target data object, that the version of the target data object updated by the first transaction is an invisible version if it is in an active state, and to determine, based on the transaction commit identifier stored in the storage space, whether the version is a visible version if it is in a committed state.

[0171] Figure 5 The transaction processing device can execute Figure 2 The implementation principle and technical effect of the transaction processing method described in the illustrated embodiment will not be described in detail. The specific manner in which each module and unit performs operations in the transaction processing device in the above embodiment has been described in detail in the embodiment of the method, and will not be described in detail here.

[0172] Figure 6 A schematic diagram of a structure of another embodiment of a transaction processing device provided in an embodiment of the present application, the device may include:

[0173] A construction module 601 is used to construct a view of a second transaction based on a most recently generated transaction commit identifier;

[0174] A search module 602 is used to search the visible version of the second transaction from the version chain according to the transaction commit identifier in the view and the transaction commit identifier indexed by the storage addresses respectively recorded in different versions in the version chain of the target data object;

[0175] The storage address corresponds to the storage space in the persistent storage medium, the storage space corresponds to a write transaction and is applied for when the write transaction is started, and the transaction commit identifier is generated and stored in the storage space when the transaction is committed.

[0176] In some embodiments, the search module may be specifically used to determine a version chain consisting of the latest version of the target data object and the historical version of the target data object stored in the rollback log; starting from the latest version in the version chain, for any version, perform the following visibility determination operation; the visibility determination operation includes:

[0177] Querying the stored transaction commit identifier of the third transaction that updates the version from the storage space indexed by the storage address of the version record;

[0178] According to the transaction commit identifier in the view and the transaction commit identifier of the third transaction, it is determined whether the version is a visible version of the second transaction.

[0179] In some embodiments, different versions of the target data object respectively record transaction identifiers; the search module queries the transaction commit identifier of the third transaction that updates the version from the storage space indexed by the storage address of the version record, which may include: when the transaction identifier of the version record is consistent with the transaction identifier of the second transaction, determining that the version is a visible version of the second transaction; otherwise, querying the transaction commit identifier of the third transaction that updates the version from the storage space indexed by the storage address of the version record.

[0180] In some embodiments, the storage space further stores a transaction identifier, and a record data is formed by the transaction identifier and the transaction commit identifier in the storage space; when the storage space is reused, the original record data of the storage space is transferred, and a link relationship between the storage space and the original record data is established;

[0181] The search module queries the transaction commit identifier of the third transaction that updates the version from the storage space indexed by the storage address of the version record. When the transaction identifier stored in the storage space indexed by the storage address of the version record is consistent with the transaction identifier of the version record, the transaction commit identifier stored in the storage space is used as the transaction commit identifier of the third transaction that updates the version; when the transaction identifier stored in the storage space is inconsistent with the transaction identifier of the version record, the transaction commit identifier corresponding to the third transaction is searched according to the link relationship between different storage spaces.

[0182] In some embodiments, the storage structure clears the record data corresponding to the earliest generated transaction commit identifier when the clearing condition is met;

[0183] The search module is also used to use the transaction commit identifier in the most recently cleared record data as the transaction commit identifier of the third transaction if the transaction commit identifier of the third transaction cannot be found.

[0184] In some embodiments, the search module searches for a transaction commit identifier of a third transaction of the version record from the storage space indexed by the storage address of the version record, including:

[0185] According to the transaction identifier of the third transaction in the version record, check whether the corresponding transaction commit identifier is saved in the memory; if so, use the transaction commit identifier saved in the memory as the transaction commit identifier of the third transaction; if not, query the transaction commit identifier of the third transaction from the storage space indexed by the storage address of the version record, and save the corresponding transaction identifier of the third transaction in the memory.

[0186] In some embodiments, when the transaction identifier stored in the storage space indexed by the storage address of the version record is consistent with the transaction identifier of the version record, the search module uses the transaction commit identifier stored in the storage space as the transaction commit identifier of the third transaction to update the version, which may include: when the transaction identifier stored in the storage space indexed by the storage address of the version record is consistent with the transaction identifier of the version record, querying the transaction status information of the third transaction to update the version from the storage space; if the transaction status information is in a committed state, using the transaction commit identifier stored in the storage space as the transaction commit identifier of the third transaction to update the version; if the transaction status information is in an active state, determining that the version is an invisible version.

[0187] Figure 6The transaction processing device can execute Figure 3 The implementation principle and technical effect of the transaction processing method described in the illustrated embodiment will not be described in detail. The specific manner in which each module and unit performs operations in the transaction processing device in the above embodiment has been described in detail in the embodiment of the method, and will not be described in detail here.

[0188] In one possible design, Figure 5 The transaction processing device of the embodiment shown and Figure 6 The transaction processing device of the embodiment shown can be deployed in a computer system, such as Figure 7 As described in, the computer system may include a storage component 701 and a processing component 702;

[0189] The storage component 701 stores one or more computer instructions, wherein the one or more computer instructions are called and executed by the processing component 702 to implement the following Figure 2 The transaction processing method shown or Figure 3 The transaction processing method described in the embodiment shown; or implementing Figure 2 The transaction processing method described in the embodiment shown in the figure and Figure 3 The transaction processing method described in the illustrated embodiment.

[0190] That is to say Figure 2 The transaction processing method described in the embodiment shown and Figure 3 The transaction processing method described in the illustrated embodiment is executed by the same computer system.

[0191] In practical applications, the computer system can be implemented as a single physical machine, or as a distributed cluster consisting of multiple physical machines, in which storage components and processing components are distributed in the cluster.

[0192] The processing component 702 may include one or more processors to execute computer instructions to complete all or part of the steps in the above method. Of course, the processing component can also be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors or other electronic components to perform the above method.

[0193] In practical applications, the processing component 702 may be composed of a multi-core processor, and the computer system is a single physical machine, forming a single-machine multi-core architecture to run the transaction system and implement Figure 2 The transaction processing method described in the embodiment shown and Figure 3The transaction processing method described in the illustrated embodiment can fully utilize hardware resources and reduce memory usage in the single-machine multi-core architecture, thereby effectively improving transaction processing performance.

[0194] The storage component 701 is configured to store various types of data to support operations at the terminal. The storage component can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0195] The storage component 701 may include a memory 7011 and a persistent storage medium 7012 , wherein the database is stored in the persistent storage medium 7012 , and a storage structure is configured in the persistent storage medium. The one or more computer instructions may be stored in the memory 7011 or the persistent storage medium 7012 .

[0196] Of course, the computer system may also include other components, such as input / output interfaces, communication components, etc. The input / output interface provides an interface between the processing component and the peripheral interface module, which may be an output device, an input device, etc. The communication component is configured to facilitate wired or wireless communication between the computing device and other devices.

[0197] Among them, the computer system can be a physical device or an elastic computing host provided by a cloud computing platform, etc. In this case, the computing device can refer to a cloud server. The above-mentioned processing components, storage components, etc. can be basic server resources rented or purchased from the cloud computing platform.

[0198] The present application also provides a computer-readable storage medium storing a computer program, wherein the computer program can achieve the above-mentioned Figure 7 The monitoring method of the illustrated embodiment.

[0199] In addition, the present application also provides a computer-readable storage medium storing a computer program, which can achieve the above-mentioned Figure 2 The transaction processing method of the embodiment shown or Figure 3 The transaction processing method of the embodiment shown or the above Figure 2 The transaction processing method of the embodiment shown and Figure 3The transaction processing method of the embodiment shown. The computer readable medium may be included in the computer system device described in the above embodiment; or it may exist independently without being assembled into the computer system. The computer readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination thereof.

[0200] The present application also provides a computer program product, which includes a computer program carried on a computer-readable storage medium. When the computer program is executed by a computer, the above-mentioned Figure 2 The transaction processing method of the embodiment shown or Figure 3 The transaction processing method of the embodiment shown or the above Figure 2 The transaction processing method of the embodiment shown and Figure 3 The transaction processing method of the illustrated embodiment. In such an embodiment, the computer program can be downloaded and installed from a network, and / or installed from a removable medium. When the computer program is executed by a processor, various functions defined in the system of the present application are executed.

[0201] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0202] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative labor.

[0203] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the prior art can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0204] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A transaction processing method, wherein: include: When a first transaction is started, applying for storage space corresponding to the first transaction from a persistent storage medium; Recording the storage address of the storage space for at least one data object updated by the first transaction respectively; When the first transaction is committed, generating a transaction commit identifier of the first transaction; The transaction commit identifier is stored in the storage space; wherein the storage space is used to query the transaction commit identifier of the first transaction, and the transaction commit identifier of the first transaction is used to find a visible version of the target data object queried by the second transaction request.

2. The method according to claim 1, wherein: Also includes: When the first transaction is started, generating a transaction identifier of the first transaction; The transaction identifier is recorded for each of the at least one data object; wherein the transaction identifier of the version record of the target data object updated by the first transaction is used to determine that the version is a visible version when it is consistent with the transaction identifier of the second transaction; otherwise, based on the storage address of the version record, the transaction commit identifier of the first transaction is queried from the storage space.

3. The method according to claim 1, wherein: Also includes: recording, for at least some of the at least one data object, a transaction commit identifier of the first transaction; or, When a query operation is performed on a current search version of any data object, a transaction commit identifier obtained from the storage space query is recorded for the current search version of the data object.

4. The method according to claim 1, wherein: When the first transaction is started, applying for storage space corresponding to the first transaction from a persistent storage medium includes: When the first transaction is started, applying for a storage space corresponding to the first transaction from a storage structure configured by a persistent storage medium, and obtaining a storage address of the storage space; Wherein, the storage structure supports reuse, and the method further comprises: The transaction identifier is stored in the storage space, wherein the transaction identifier and the transaction commit identifier constitute a record data; When the storage space is reused, the original record data stored in the storage space is transferred and a link relationship between the storage space and the original record data is established; the link relationship is used to find the target record data corresponding to the transaction identifier of the first transaction to obtain the transaction commit identifier of the first transaction.

5. The method according to claim 4, wherein: Also includes: When the storage structure meets the clearing condition, the record data corresponding to the earliest generated transaction commit identifier in the storage structure is cleared; wherein the transaction commit identifier in the most recently cleared record data is used as the transaction commit identifier of the first transaction when the transaction commit identifier of the first transaction cannot be queried from the storage structure.

6. A transaction processing method, wherein: include: Building a view of the second transaction based on the most recently generated transaction commit identifier; According to the transaction commit identifier in the view and the transaction commit identifiers indexed by the storage addresses respectively recorded in different versions in the version chain of the target data object, searching the visible version of the second transaction from the version chain; The storage address corresponds to a storage space in a persistent storage medium, the storage space corresponds to a write transaction and is applied for when the write transaction is started, and the transaction commit identifier is generated and stored in the storage space when the transaction is committed.

7. The method according to claim 6, wherein: The searching the visible version of the second transaction from the version chain according to the transaction commit identifier in the view and the transaction commit identifier indexed by the storage addresses respectively recorded by different versions in the version chain of the target data object comprises: Determine a version chain consisting of the latest version of the target data object and the historical versions of the target data object stored in the rollback log; Starting from the latest version in the version chain, for any version, the following visibility determination operation is performed; the visibility determination operation includes: Querying, from the storage space indexed by the storage address of the version record, a stored transaction commit identifier of the third transaction that updates the version; According to the transaction commit identifier in the view and the transaction commit identifier of the third transaction, it is determined whether the version is a visible version of the second transaction.

8. The method according to claim 7, wherein: Different versions of the target data object respectively record transaction identifiers; The querying of the transaction commit identifier of the third transaction that updates the version from the storage space indexed by the storage address of the version record includes: When the transaction identifier of the version record is consistent with the transaction identifier of the second transaction, the version is determined to be a visible version of the second transaction; otherwise, the transaction commit identifier of the third transaction that updates the version is queried from the storage space indexed by the storage address of the version record.

9. The method according to claim 7 or 8, wherein: The storage space also stores a transaction identifier, and a record data is formed by the transaction identifier and the transaction commit identifier in the storage space; when the storage space is reused, the original record data of the storage space is transferred and a link relationship between the storage space and the original record data is established; The querying of the transaction commit identifier of the third transaction that updates the version from the storage space indexed by the storage address of the version record includes: When the transaction identifier stored in the storage space indexed by the storage address of the version record is consistent with the transaction identifier of the version record, using the transaction commit identifier stored in the storage space as the transaction commit identifier of the third transaction that updates the version; When the transaction identifier stored in the storage space is inconsistent with the transaction identifier in the version record, the transaction commit identifier corresponding to the third transaction is searched according to the link relationship of the storage space.

10. The method according to claim 9, wherein: The storage structure configured by the persistent storage medium clears the record data corresponding to the earliest generated transaction commit identifier when the clearing condition is met; the method further includes: If the transaction commit identifier of the third transaction cannot be found according to the link relationship of the storage space, the transaction commit identifier in the most recently cleared record data is used as the transaction commit identifier of the third transaction.

11. The method according to claim 7 or 8, wherein: Querying the transaction commit identifier of the third transaction of the version record from the storage space indexed by the storage address of the version record includes: According to the transaction identifier of the third transaction in the version record, searching in the memory whether a corresponding transaction commit identifier is saved; If so, using the transaction commit identifier stored in the memory as the transaction commit identifier of the third transaction; If not, query the transaction commit identifier of the third transaction from the storage space indexed by the storage address of the version record, and save the transaction identifier of the third transaction into the memory.

12. The method according to claim 9, wherein: When the transaction identifier stored in the storage space indexed by the storage address of the version record is consistent with the transaction identifier of the version record, using the transaction commit identifier stored in the storage space as the transaction commit identifier of the third transaction that updates the version includes: When the transaction identifier stored in the storage space indexed by the storage address of the version record is consistent with the transaction identifier of the version record, querying the transaction status information of the third transaction that updates the version from the storage space; If the transaction status information is a commit status, using the transaction commit identifier stored in the storage space as a transaction commit identifier of a third transaction that updates the version; If the transaction status information is in an active state, it is determined that the version is an invisible version.

13. A computer system, wherein: It includes a processing component and a storage component; the storage component includes a memory and a persistent storage medium; The storage component stores one or more computer instructions; the one or more computer instructions are used to be called and executed by the processing component to implement the transaction processing method as described in any one of claims 1 to 5, or to implement the transaction processing method as described in any one of claims 6 to 12.

14. A computer storage medium, wherein: A computer program is stored, and when the computer program is executed by a computer, it implements the transaction processing method as described in any one of claims 1 to 5, or realizes the transaction processing method as described in any one of claims 6 to 12.

Images