CN110515707B - Deterministic concurrency control method and system based on advanced transaction processing - Google Patents
Deterministic concurrency control method and system based on advanced transaction processing Download PDFInfo
- Publication number
- CN110515707B CN110515707B CN201910779763.3A CN201910779763A CN110515707B CN 110515707 B CN110515707 B CN 110515707B CN 201910779763 A CN201910779763 A CN 201910779763A CN 110515707 B CN110515707 B CN 110515707B
- Authority
- CN
- China
- Prior art keywords
- transaction
- data
- execution
- transactions
- current
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2453—Query optimisation
- G06F16/24532—Query optimisation of parallel queries
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
Abstract
The invention provides a deterministic concurrency control method and a deterministic concurrency control system based on pre-transaction processing, which fully improve the expandability and the performance of the transaction processing by placing the execution of the transaction before the transaction scheduling on the basis of deterministic transaction processing; the correctness of the transaction execution is ensured through checking and re-executing; deterministic execution of transactions is satisfied by explicit waiting and ensuring that each transaction is re-executed at most once; by using multi-version data storage, read-only transactions are prevented from blocking transactions; by recording the address of the data required by the transaction, the re-execution after the transaction verification fails is accelerated. Compared with the prior art, the invention can fully utilize the concurrency of transactions and greatly improve the transaction processing capability of the deterministic database; the scheduling of the transaction can be accelerated by multiplexing data information collected during the execution of the transaction; an additional mechanism is not needed to determine the complete read-write set of the transaction, and the additional performance overhead of the prior art is avoided.
Description
Technical Field
The invention relates to the field of distributed concurrency control, in particular to a deterministic concurrency control method and system based on advanced transaction processing.
Background
In order to cope with the explosive data growth of the internet, distributed databases are widely used in different fields, and the requirements on the performance and the distributed expandability of the databases are higher and higher. In recent years, the concept of deterministic databases has been proposed. The database system determines a global execution sequence for the transaction in advance, and ensures that the transaction is executed on each server according to the sequence. Compared with the traditional distributed database, each server of the deterministic database can independently achieve the consistency of the decision of whether the transaction is submitted or not, and a distributed submission protocol is not needed to ensure the atomicity of the transaction submission, so that the overhead caused by the distributed submission protocol is avoided, and the distributed expandability is improved; meanwhile, the deterministic database can schedule transactions according to a predetermined transaction execution sequence, reduce conflicts in a high-competition transaction scene, and improve the database performance in the high-competition scene. Therefore, the deterministic database is an emerging database that is becoming increasingly accepted and used by both academia and industry.
The deterministic database uses deterministic concurrency control to ensure deterministic execution of transactions according to a predetermined order of execution of transactions. Deterministic execution of a transaction refers to: the end result of the execution of the transactions is the same as if the transactions were executed serially in the given order. Thus, the deterministic database improves the performance of transactional execution by letting transactions without conflicts execute in parallel; the certainty of execution is guaranteed by having conflicting transaction executions follow strictly a predetermined execution order. In addition, deterministic databases are designed and implemented to exclude non-deterministic factors such as random variables, server crashes, etc., ensuring that the execution result of a transaction is uniquely deterministic given the same inputs.
Currently, the mainstream deterministic database systems use a deterministic lock-based single-threaded scheduler to schedule transactions, ensuring deterministic execution of transactions. The deterministic lock scheduling mode is as follows: and scheduling the transactions in sequence according to a predetermined transaction execution sequence, determining a read-write set of the transactions before the transactions are executed, applying for read-write locks for all data in the transaction read-write set, and starting to execute after the transactions apply for all required read-write locks. The scheduling mode uses the read-write lock to ensure that read-write conflict and write-write conflict cannot occur among the executing transactions, and the relative execution sequence of the mutually conflicting transactions is consistent with the predetermined execution sequence, thereby meeting the deterministic execution of the transactions.
However, the single-threaded scheduling of the existing deterministic database based on the deterministic lock can cause the problem of low extensibility of the deterministic database, which is caused by the following three problems:
1. single threaded scheduling becomes a system performance bottleneck. To ensure the final deterministic execution of a transaction, it is necessary to schedule the transaction, taking a lock for the transaction, in a given execution order on a single thread. Meanwhile, the deterministic lock needs to apply for a fine-grained lock for all read-write sets of the transaction, and the index overhead of the lock is high, which further causes low single-thread scheduling performance.
2. Limiting the concurrency of transactions. Deterministic locks guarantee that all potentially conflicting transactions cannot be executed in parallel through the lock, and thus this conservative scheduling approach results in the original transaction that can be executed in parallel having to have one side wait, resulting in a decrease in the performance of the overall transaction processing.
3. The transaction type is limited. Deterministic locks require that locks for all read-write sets be applied for a transaction before the transaction executes, and thus the read-write sets of the transaction must be foreseen. However, for transactions that need to determine the read-write set at execution time, the read-write set must be predetermined by an additional mechanism to be scheduled by the deterministic lock, resulting in additional performance overhead.
In the academia, the design of existing deterministic database systems all choose a mode of scheduling before transaction execution. Because transaction scheduling requires the collection of a large amount of transaction information, some of which can generally only be determined when a transaction is actually executed, existing related work can be limited in performance by high-overhead transaction scheduling.
At present, no deterministic concurrency control or database system works, and advanced transaction processing is tried, namely, a mode that the execution of a transaction is arranged before scheduling. Therefore, previous work is not comprehensive and has some blank in the study of transaction scheduling for deterministic databases.
A related art related to the present application is patent document CN 104679881B, and provides a concurrency control method including: receiving at least two transaction operation requests, wherein each transaction operation request in the at least two transaction operation requests comprises operation object information and operation type information, the operation object information is used for indicating an operation object of the transaction operation request, and the operation type information comprises write operation or read operation; performing lock application according to the at least two transaction operation requests; determining whether the application passes according to the request lock state and the current lock state of the lock application; if so, determining to use the request lock state to perform concurrent control on the at least two transaction operation requests; wherein the lock state includes at least three modes: the method comprises a sharing read mode, a sharing write mode and an exclusive mode, wherein the sharing write mode comprises the step of allowing more than or equal to two write operations to simultaneously write the operation object. The concurrency control method improves the concurrency throughput capacity of the database system.
Disclosure of Invention
Aiming at the defects in the prior art, the invention aims to provide a deterministic concurrency control method and system based on advanced transaction processing.
The invention provides a deterministic concurrency control method based on advanced transaction processing, which comprises the following steps:
initial setting step: setting the current transaction state as unexecuted, blocking the execution of the current transaction, sequencing all the transactions with the state as unexecuted in the server, recording the dependent transaction of the current transaction if the current task is at the top of the sequencing sequence, and setting the current transaction state as executing;
the method comprises the following steps: judging whether all the states in the server are the execution completion of the executed transaction, if not, executing the next transaction operation, and if so, entering blocking or executing verification according to the transaction dependent state of the current transaction;
and (3) executing a verification step: if the dependent transaction state of the current transaction is committed, performing execution verification on the data in the read-write set of the current transaction, if the data is not modified, committing and updating, setting the state of the current transaction as committed, ending the transaction execution, and if the data is modified, re-executing the current transaction.
Preferably, the next transaction operation in the pre-execution step includes:
a data reading step: if the next transaction operation is a read operation, reading data through the index to perform temporary caching, recording metadata of the read data, and continuously judging whether all the transactions in the execution state in the server are completely executed;
a data writing step: if the next transaction operation is a write operation, which means that the read data is updated, the update of the write operation is recorded in the temporary cache, and whether all the transactions in the executing state in the server are executed is continuously judged.
And a data inserting step: and if the next transaction operation is an insert operation, inserting null data and recording metadata of the null data, recording the update of the insert operation in a temporary cache, and continuously judging whether all the transactions in the execution state in the server are completely executed.
Preferably, the performing the verification step includes:
and a data verification step: for data in a read-write set of a current transaction, verifying whether the data in the read-write set is modified or not through recorded metadata, directly reading a current version of the data through a recorded data address, comparing current version information of the data with recorded data version information, if the current version information is consistent with the data version information, judging that the data is modified, and executing submission, otherwise, judging that the data is modified, and executing the current transaction again;
and re-executing the steps: and judging whether all the transaction operations are executed again, and if the unexecuted transaction exists, executing according to the fact that the next transaction operation is a read operation, a write operation or an insert operation. In the execution process, if the operated data is the data which has been operated in the pre-execution step, the corresponding data can be directly accessed through the data address in the metadata. If all the transaction operations are executed, performing submission;
and (3) executing a submitting step: and updating and submitting all data recorded in the temporary cache into the database through the data address in the metadata, setting the state of the dependent transaction of the current transaction as committed, and finishing the execution of the current transaction.
Preferably, the metadata includes a data address and version information, the data address is used for directly accessing data in the data storage, so as to reduce the overhead of repeatedly indexing data, and the data version information is a version number of the data when accessed, so as to check whether the data is modified.
Preferably, after receiving the transaction sent by the client, the server allocates a unique identifier to the transaction, the identifier determines a global execution sequence for the transaction, and when performing transaction ordering, the server determines a relative execution sequence of the two transactions by comparing the identifiers of the two transactions.
The invention provides a deterministic concurrency control system based on advanced transaction processing, which comprises:
an initial setting module: setting the current transaction state as unexecuted, blocking the execution of the current transaction, sequencing all the transactions with the state as unexecuted in the server, recording the dependent transaction of the current transaction if the current task is at the top of the sequencing sequence, and setting the current transaction state as executing;
a pre-execution module: judging whether all the states in the server are the execution completion of the executed transaction, if not, executing the next transaction operation, and if so, entering blocking or executing verification according to the transaction dependent state of the current transaction;
and executing a checking module: if the dependent transaction state of the current transaction is committed, performing execution verification on the data in the read-write set of the current transaction, if the data is not modified, committing and updating, setting the state of the current transaction as committed, ending the transaction execution, and if the data is modified, re-executing the current transaction.
Preferably, the next transaction operation in the pre-execution module includes:
a data reading module: if the next transaction operation is a read operation, reading data through the index to perform temporary caching, recording metadata of the read data, and continuously judging whether all the transactions in the execution state in the server are completely executed;
a data writing module: if the next transaction operation is a write operation, which means that the read data is updated, the update of the write operation is recorded in the temporary cache, and whether all the transactions in the executing state in the server are executed is continuously judged.
Inserting a data module: and if the next transaction operation is an insert operation, inserting null data and recording metadata of the null data, recording the update of the insert operation in a temporary cache, and continuously judging whether all the transactions in the execution state in the server are completely executed.
Preferably, the execution verification module includes:
a data checking module: for data in a read-write set of a current transaction, verifying whether the data in the read-write set is modified or not through recorded metadata, directly reading a current version of the data through a recorded data address, comparing current version information of the data with recorded data version information, if the current version information is consistent with the data version information, judging that the data is modified, and executing submission, otherwise, judging that the data is modified, and executing the current transaction again;
and the re-execution module: and judging whether all the transaction operations are executed again, and if the unexecuted transaction exists, executing according to the fact that the next transaction operation is a read operation, a write operation or an insert operation. In the execution process, if the operated data is the data which is already operated in the pre-execution module, the corresponding data can be directly accessed through the data address in the metadata. If all the transaction operations are executed, performing submission;
executing a submission module: and updating and submitting all data recorded in the temporary cache into the database through the data address in the metadata, setting the state of the dependent transaction of the current transaction as committed, and finishing the execution of the current transaction.
Preferably, the metadata includes a data address and version information, the data address is used for directly accessing data in the data storage, so as to reduce the overhead of repeatedly indexing data, and the data version information is a version number of the data when accessed, so as to check whether the data is modified.
Preferably, after receiving the transaction sent by the client, the server allocates a unique identifier to the transaction, the identifier determines a global execution sequence for the transaction, and when performing transaction ordering, the server determines a relative execution sequence of the two transactions by comparing the identifiers of the two transactions.
Compared with the prior art, the invention has the following beneficial effects:
1. the transaction is allowed to execute in advance without scheduling, the concurrency among the transactions is fully utilized, and the certainty and the correctness of the execution of the transaction are ensured through waiting and checking.
2. The transaction is allowed to be executed in advance before scheduling, so that the transaction scheduling can multiplex transaction information acquired during execution, and the scheduling of the transaction is accelerated.
3. By using multi-version data storage, read-only transactions are allowed to read data of specific versions, the problem that the read-only transactions block transaction execution is effectively avoided, and the performance of a deterministic database is further improved.
4. When the transaction check fails to be executed again, the operation is executed again at most once, and the re-execution can multiplex the data address recorded in the first execution so as to accelerate the re-execution.
5. The transaction read-write set does not need to be determined in advance, and the extra overhead of determining the transaction read-write set before execution is avoided.
Drawings
Other features, objects and advantages of the invention will become more apparent upon reading of the detailed description of non-limiting embodiments with reference to the following drawings:
FIG. 1 is a flow chart of the present invention.
Detailed Description
The present invention will be described in detail with reference to specific examples. The following examples will assist those skilled in the art in further understanding the invention, but are not intended to limit the invention in any way. It should be noted that it would be obvious to those skilled in the art that various changes and modifications can be made without departing from the spirit of the invention. All falling within the scope of the present invention.
According to the deterministic concurrency control method for the advanced transaction processing, provided by the invention, when a client initiates a request, a transaction needing to be executed is sent to a server storing required data. According to the concurrency control method, after receiving the transaction sent by the client, the server allocates a unique identifier for the transaction, so as to determine the global execution sequence for the transaction. The concurrency control method ensures that the final execution result of a series of transactions is the same as the result of executing serially in a given execution order. It is characterized in that an executing transaction (current transaction) sequentially executes the following steps:
1. the method comprises the following initial steps: and setting the current transaction state as 'not executed', and executing the ordering step 2.
2. A sorting step: and blocking the execution of the current transaction until the current transaction becomes the transaction with the state of 'not executed' on the server, wherein the execution sequence is the most advanced transaction. Then, the identifier of the dependent transaction of the current transaction is recorded, the current transaction state is set to be 'executing', and the step 3 of pre-execution is executed.
3. The method comprises the following steps: it is determined whether all transaction operations have been performed. If the transaction operation is not executed, executing a corresponding data reading step 4 or a corresponding data writing step 5 according to the fact that the next transaction operation is a writing operation or a reading operation; if all transaction operations have been executed, a wait step 6 is performed.
4. A data reading step: and (3) reading the required data by indexing into a temporary cache, recording the metadata of the read data, and executing the step 3 in advance.
5. A data writing step: and recording the update of the transaction write operation in a temporary cache, and executing the step 3 in advance.
6. A waiting step: current transaction execution is blocked until the dependent transaction state of the current transaction is "committed". A verification step 7 is performed.
7. A checking step: and verifying whether the data read and written in the pre-execution step is modified or not through the recorded metadata for the data in all the read and write sets of the transaction. And directly reading the current version of the data through the recorded data address, and comparing the current version information of the data with the recorded data version information. If the verification of the version information is successful for all data, i.e. all data are not modified, a commit step 11 is performed; if not successful, i.e. there is any data modified, a re-execution of step 8 is performed.
8. And re-executing the steps: it is determined whether all transaction operations have been re-executed. If the transaction operation is not executed, executing a corresponding data re-reading step 9 or data re-writing step 10 according to the fact that the next transaction operation is a writing operation or a reading operation; if all transaction operations have been executed, a commit step 11 is performed.
9. And re-reading data: and (5) reading the data into a temporary cache, recording the metadata of the read data, and executing the step 8 again.
10. And rewriting data: the update of the transactional write operation is recorded in the temporary cache and a re-execution step 8 is performed.
11. A submitting step: all data updates recorded in the temporary cache are committed into the database by the data address in the metadata, ending step 12.
12. And (5) finishing the steps: and setting the current transaction state as 'committed', and finishing the execution of the transaction.
In particular, persistent data is stored with multi-version data. The transaction indexes the corresponding data according to the Key (Key) of the data, and then uses the unique identifier of the transaction as a version number to determine the version of the data to be accessed. In addition, the used data storage should ensure that the address where the transaction is located does not change in the life cycle of the transaction from creation to destruction, and the transaction can directly access data through the recorded data address.
Specifically, the metadata of the data includes a data address and version information. The data address is used for directly accessing data in the data storage, and the overhead of repeatedly indexing the data is reduced. The data version information is a version number of data when the data is accessed, and is used to verify whether the data is modified.
Specifically, the sorting step 2 may determine the relative execution order of the two transactions by comparing the identifiers of the two transactions, and further determine whether the current transaction is the transaction with the earliest execution order among the transactions with the "unexecuted" status on the server.
Specifically, the dependent transactions of the current transaction described in the ordering step 2 and the waiting step 6 refer to the last transaction containing a write operation among the transactions that are executed in the server in the sequence before the current transaction.
Specifically, in the data writing step 5, if the write operation is an insert operation, corresponding null data needs to be inserted into the data storage, and metadata of the data also needs to be recorded.
Specifically, in the step 9 of re-reading data, if the current transaction has recorded metadata of data to be read, the data is directly read according to the recorded data address; if the transaction has not recorded the metadata to be read, the data is read by the index.
Specifically, in the initial step 1, the sorting step 2, the waiting step 6, and the ending step 12, the state of each transaction on the server is stored in a transaction information table maintained by the server separately, and the state of the transaction can be accessed by indexing a transaction identifier.
According to the invention, a deterministic concurrency control system for advanced transactions is provided. When the client initiates a request, the client sends a transaction to be executed to the server storing the required data. According to the database system, after receiving a transaction sent by a client, a server allocates a unique identifier for the transaction to determine a global execution sequence for the transaction. The database system will ensure that the final execution result of a series of transactions is the same as the result of executing serially in a given execution order. The method is characterized in that an executing transaction (current transaction) sequentially executes the following modules:
1. an initial module: and setting the current transaction state as 'not executed', and executing the sequencing module 2.
2. A sorting module: and blocking the execution of the current transaction until the current transaction becomes the transaction with the state of 'not executed' on the server, wherein the execution sequence is the most advanced transaction. Then, the identifier of the dependent transaction of the current transaction is recorded, the current transaction state is set to "executing", and the pre-execution module 3 is executed.
3. A pre-execution module: it is determined whether all transaction operations have been performed. If the transaction operation is not executed, executing the corresponding data reading module 4 or data writing module 5 according to the fact that the next transaction operation is a writing operation or a reading operation; if all transaction operations have been executed, the wait module 6 is executed.
4. A data reading module: and the data required by index reading enters a temporary cache, the metadata of the read data is recorded, and the pre-execution module 3 is executed.
5. A data writing module: and recording the update of the transaction write operation in a temporary cache, and executing the pre-execution module 3.
6. A waiting module: current transaction execution is blocked until the dependent transaction state of the current transaction is "committed". The verification module 7 is executed.
7. A checking module: and verifying whether the data read and written in the pre-execution module is modified or not through the recorded metadata for the data in all the read and write sets of the transaction. And directly reading the current version of the data through the recorded data address, and comparing the current version information of the data with the recorded data version information. If the verification of the version information is successful for all the data, i.e. all the data are not modified, the commit module 11 is executed; if not successful, i.e. there is any data modified, the re-execution module 8 is executed.
8. And the re-execution module: it is determined whether all transaction operations have been re-executed. If the transaction operation is not executed, executing the corresponding re-reading data module 9 or re-writing data module 10 according to the fact that the next transaction operation is a writing operation or a reading operation; if all transaction operations have been executed, the commit module 11 is executed.
9. And a data re-reading module: and the read data enters a temporary cache, the metadata of the read data is recorded, and the re-execution module 8 is executed.
10. The rewriting data module: the update of the transactional write operation is recorded in a temporary cache and the re-execution module 8 is executed.
11. A submission module: all data updates recorded in the temporary cache are committed into the database by the data address in the metadata, and the end module 12 is executed.
12. An end module: and setting the current transaction state as 'committed', and finishing the execution of the transaction.
The deterministic concurrency control system of the preliminary transaction processing provided by the invention can be realized by the step flow of the deterministic concurrency control method of the preliminary transaction processing. The deterministic concurrency control method of the preliminary transaction can be understood as a preferred example of the deterministic concurrency control system of the preliminary transaction by those skilled in the art.
As shown in FIG. 1, in step 1, the current transaction state is first set to "not executed", marking that the transaction has begun to be processed. After the above steps are completed, step 2 is performed.
In step 2, the transaction whose execution order is before the current transaction and whose state is "not executed" is queried, and the execution of the current transaction is blocked.
In the above step execution, the relative execution order of different transactions can be obtained by comparing the transaction identifiers.
In the execution of the above steps, if the query result is null, that is, the current transaction is the transaction with the earliest execution sequence among the transactions with the state of "not executed", recording the identifier of the dependent transaction of the current transaction, setting the state of the current transaction as "executing", and starting to execute step 3; otherwise, continuing to execute the step 2.
In step 3, the next operation type to be executed is first determined. If the next operation is a read operation, reading corresponding data and metadata (the metadata comprises a data address and version information of the data) in the data storage through indexing and recording the data and the metadata in a temporary cache; if the next operation is a write operation, the update of the transactional write operation is recorded in a temporary cache.
In the above step, if the next operation is an insert operation in the write operation classification, it is necessary to insert corresponding null data into the data storage for the data of the insert operation, and record the metadata of the null data, and then record the update of the transaction write operation in the temporary cache.
After the above steps are completed, if there are still unexecuted operations, continuing to execute step 3; otherwise, step 4 is executed.
In step 4, the state of the dependent transaction of the current transaction is queried and execution of the current transaction is blocked.
In the step execution, if the queried state of the dependent transaction is 'committed', the step 5 is started to be executed; otherwise, continue to step 4.
In step 5, for each data in the read-write set of the current transaction, it is determined whether the data was modified within the period of time from the read from step 3 to the verified at step 5.
In the above step, the current version information of the data is directly read using the data address recorded at step 3 and compared with the version information of the data recorded at step 3. If the version information is different, the data is modified; otherwise, it indicates that the data is not modified.
In the above step, if any data is modified, the transaction check fails, and step 6 is executed; otherwise, the transaction is verified successfully, and step 7 is executed.
In step 6, the transaction needs to be re-executed due to the failure of the check. First, the kind of the next operation to be executed is determined. If the next operation is a read operation, reading the data and the metadata into a temporary cache; if the next operation is a write operation, the update of the transactional write operation is recorded in a temporary cache.
In the above-described step execution, in the case where the next operation is a read operation, if the metadata of the read data has been recorded in step 3, the data and the metadata are read directly using the recorded data address; otherwise, the data and metadata in the data store are read by the index.
After the above steps are completed, if there are still unexecuted operations, continue to execute step 6; otherwise, step 7 is performed.
In step 7, the transaction commits the update of the data directly into the data store via the recorded data address. And when all data are submitted, setting the transaction state as 'submitted'.
And finishing the current transaction execution after the steps are completed.
On the basis of deterministic transaction processing, the invention fully improves the expandability and performance of the transaction processing by placing the execution of the transaction before the transaction scheduling; the correctness of the transaction execution is ensured through checking and re-executing; deterministic execution of transactions is satisfied by explicit waiting and ensuring that each transaction is re-executed at most once; by using multi-version data storage, read-only transactions are prevented from blocking transactions; by recording the address of the data required by the transaction, the re-execution after the transaction verification fails is accelerated. Compared with the prior art, the invention can fully utilize the concurrency of transactions and greatly improve the transaction processing capability of the deterministic database; the invention can multiplex the data information collected during the transaction execution to accelerate the scheduling of the transaction; the invention does not need an additional mechanism to determine the complete read-write set of the transaction, thereby avoiding the additional performance overhead of the prior art.
One skilled in the art will appreciate that, in addition to the method and system for concurrency control and the steps and modules thereof provided by the present invention being implemented by reading program codes, the method and system for concurrency control and the steps and modules thereof provided by the present invention can be implemented by completely programming the steps and modules thereof in logic form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Therefore, the concurrent control method and system provided by the present invention, and the steps and modules thereof can be regarded as a hardware component, and the steps and modules included therein for implementing various program logics can also be regarded as structures in the hardware component; the steps and modules for performing the various functions may also be considered as both software programs for performing the methods and structures within the hardware components.
The foregoing description of specific embodiments of the present invention has been presented. It is to be understood that the present invention is not limited to the specific embodiments described above, and that various changes or modifications may be made by one skilled in the art within the scope of the appended claims without departing from the spirit of the invention. The embodiments and features of the embodiments of the present application may be combined with each other arbitrarily without conflict.
Claims (10)
1. A deterministic concurrency control method based on advanced transaction processing, comprising:
initial setting step: setting the current transaction state as unexecuted, blocking the execution of the current transaction, sequencing all the transactions with the state as unexecuted in the server, recording the dependent transaction of the current transaction if the current task is at the top of the sequencing sequence, and setting the current transaction state as executing;
the method comprises the following steps: judging whether all the transactions in the server with the states of execution are executed completely, and if not, executing the next transaction operation; if the execution is finished, executing a waiting step;
a waiting step: blocking the current transaction from being executed until the dependent transaction state of the current transaction is 'committed', and executing a checking step;
and (3) executing a verification step: if the dependent transaction state of the current transaction is committed, performing execution verification on the data in the read-write set of the current transaction, if the data is not modified, committing and updating, setting the state of the current transaction as committed, ending the transaction execution, and if the data is modified, re-executing the current transaction.
2. The deterministic concurrency control method based on preliminary transaction processing as claimed in claim 1, wherein the next transaction operation in the preliminary execution step comprises:
a data reading step: if the next transaction operation is a read operation, reading data through the index to perform temporary caching, recording metadata of the read data, and continuously judging whether all the transactions in the execution state in the server are completely executed;
a data writing step: if the next transaction operation is a write operation, which means that the read data is updated, recording the update of the write operation in a temporary cache, and continuously judging whether all the transactions in the execution state in the server are completely executed;
and a data inserting step: and if the next transaction operation is an insert operation, inserting null data and recording metadata of the null data, recording the update of the insert operation in a temporary cache, and continuously judging whether all the transactions in the execution state in the server are completely executed.
3. The advanced transaction based deterministic concurrency control method of claim 1, wherein said performing a verification step comprises:
and a data verification step: for data in a read-write set of a current transaction, verifying whether the data in the read-write set is modified or not through recorded metadata, directly reading a current version of the data through a recorded data address, comparing current version information of the data with recorded data version information, if the current version information is consistent with the data version information, judging that the data is modified, and executing submission, otherwise, judging that the data is modified, and executing the current transaction again;
and re-executing the steps: judging whether all the transaction operations are executed again, and if the unexecuted transaction exists, executing according to the fact that the next transaction operation is a read operation, a write operation or an insert operation; in the execution process, if the operated data is the data which is operated in the pre-execution process, the corresponding data can be directly accessed through the data address in the metadata, and if all the transaction operations are executed, the commit is executed;
and (3) executing a submitting step: and updating and submitting all data recorded in the temporary cache into the database through the data address in the metadata, setting the state of the dependent transaction of the current transaction as committed, and finishing the execution of the current transaction.
4. The advanced transaction based deterministic concurrency control method of claim 2, wherein the metadata includes data addresses for directly accessing data in the data store to reduce overhead of repeatedly indexing data and version information for verifying whether data is modified, the version information being a version number of the data when accessed.
5. The deterministic concurrency control method based on advanced transaction processing as claimed in claim 1, wherein the server assigns a unique identifier to the transaction after receiving the transaction sent by the client, the identifier determines a global execution order for the transaction, and when performing transaction ordering, the relative execution order of the two transactions is determined by comparing the identifiers of the two transactions.
6. A deterministic concurrency control system based on advanced transactions, comprising:
an initial setting module: setting the current transaction state as unexecuted, blocking the execution of the current transaction, sequencing all the transactions with the state as unexecuted in the server, recording the dependent transaction of the current transaction if the current task is at the top of the sequencing sequence, and setting the current transaction state as executing;
a pre-execution module: judging whether all the transactions in the server in the executing state are executed completely, if not, executing the next transaction operation, and if so, executing a waiting step;
a waiting step: blocking the current transaction from being executed until the dependent transaction state of the current transaction is 'committed', and executing a checking step;
and executing a checking module: if the dependent transaction state of the current transaction is committed, performing execution verification on the data in the read-write set of the current transaction, if the data is not modified, committing and updating, setting the state of the current transaction as committed, ending the transaction execution, and if the data is modified, re-executing the current transaction.
7. The system according to claim 6, wherein the pre-transaction based deterministic concurrency control system further comprises the pre-execution module for performing the next transaction operation:
a data reading module: if the next transaction operation is a read operation, reading data through the index to perform temporary caching, recording metadata of the read data, and continuously judging whether all the transactions in the execution state in the server are completely executed;
a data writing module: if the next transaction operation is a write operation, which means that the read data is updated, recording the update of the write operation in a temporary cache, and continuously judging whether all the transactions in the execution state in the server are completely executed;
inserting a data module: and if the next transaction operation is an insert operation, inserting null data and recording metadata of the null data, recording the update of the insert operation in a temporary cache, and continuously judging whether all the transactions in the execution state in the server are completely executed.
8. The advanced transaction based deterministic concurrency control system of claim 6 wherein said execution verification module comprises:
a data checking module: for data in a read-write set of a current transaction, verifying whether the data in the read-write set is modified or not through recorded metadata, directly reading a current version of the data through a recorded data address, comparing current version information of the data with recorded data version information, if the current version information is consistent with the data version information, judging that the data is modified, and executing submission, otherwise, judging that the data is modified, and executing the current transaction again;
and the re-execution module: judging whether all the transaction operations are executed again, and if the unexecuted transaction exists, executing according to the fact that the next transaction operation is a read operation, a write operation or an insert operation; in the execution process, if the operated data is the data which is operated in the pre-execution module, the corresponding data can be directly accessed through the data address in the metadata, and if all the transaction operations are executed, the commit is executed;
executing a submission module: and updating and submitting all data recorded in the temporary cache into the database through the data address in the metadata, setting the state of the dependent transaction of the current transaction as committed, and finishing the execution of the current transaction.
9. The advanced transaction based deterministic concurrency control system of claim 7 wherein the metadata includes data addresses for accessing data directly in the data store, reducing overhead of repeating the index data, and version information, which is the version number of the data when accessed, for checking whether the data is modified.
10. The deterministic concurrency control system based on preliminary transaction processing as claimed in claim 6, wherein the server assigns unique identifiers to the transactions after receiving the transactions sent by the client, the identifiers determine the global execution order for the transactions, and when ordering the transactions, the relative execution order of the two transactions is determined by comparing the identifiers of the two transactions.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910779763.3A CN110515707B (en) | 2019-08-22 | 2019-08-22 | Deterministic concurrency control method and system based on advanced transaction processing |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910779763.3A CN110515707B (en) | 2019-08-22 | 2019-08-22 | Deterministic concurrency control method and system based on advanced transaction processing |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110515707A CN110515707A (en) | 2019-11-29 |
| CN110515707B true CN110515707B (en) | 2022-02-25 |
Family
ID=68626532
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910779763.3A Active CN110515707B (en) | 2019-08-22 | 2019-08-22 | Deterministic concurrency control method and system based on advanced transaction processing |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110515707B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112100188A (en) * | 2020-09-01 | 2020-12-18 | 上海交通大学 | Concurrent control method and system based on machine learning |
| CN112148930B (en) * | 2020-09-28 | 2023-01-06 | 上海交通大学 | Method, system and medium for graph database system transaction processing based on RTM |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102299959A (en) * | 2011-08-22 | 2011-12-28 | 北京邮电大学 | Load balance realizing method of database cluster system and device |
| CN104239357A (en) * | 2013-06-21 | 2014-12-24 | Sap欧洲公司 | Concurrent request processing for database transaction |
| CN105955801A (en) * | 2015-12-21 | 2016-09-21 | 上海交通大学 | RDMA and HTM based distributed optimistic concurrency control method |
| CN106897123A (en) * | 2015-12-21 | 2017-06-27 | 阿里巴巴集团控股有限公司 | Database operation method and device |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9652491B2 (en) * | 2013-04-15 | 2017-05-16 | International Business Machines Corporation | Out-of-order execution of strictly-ordered transactional workloads |
| US10120802B2 (en) * | 2015-09-23 | 2018-11-06 | International Business Machines Corporation | Transactional memory coherence control |
-
2019
- 2019-08-22 CN CN201910779763.3A patent/CN110515707B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102299959A (en) * | 2011-08-22 | 2011-12-28 | 北京邮电大学 | Load balance realizing method of database cluster system and device |
| CN104239357A (en) * | 2013-06-21 | 2014-12-24 | Sap欧洲公司 | Concurrent request processing for database transaction |
| CN105955801A (en) * | 2015-12-21 | 2016-09-21 | 上海交通大学 | RDMA and HTM based distributed optimistic concurrency control method |
| CN106897123A (en) * | 2015-12-21 | 2017-06-27 | 阿里巴巴集团控股有限公司 | Database operation method and device |
Non-Patent Citations (1)
| Title |
|---|
| 基于MANET的移动数据库系统事务管理的研究与实现;彭加亮;《中国优秀硕士学位论文全文库 信息科技辑 I138-283》;20050831;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110515707A (en) | 2019-11-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8037476B1 (en) | Address level log-based synchronization of shared data | |
| US8271739B2 (en) | Memory control apparatus, program, and method | |
| US5983225A (en) | Parameterized lock management system and method for conditional conflict serializability of transactions | |
| US11386065B2 (en) | Database concurrency control through hash-bucket latching | |
| US8973004B2 (en) | Transactional locking with read-write locks in transactional memory systems | |
| US20180322158A1 (en) | Changing concurrency control modes | |
| US20070198978A1 (en) | Methods and apparatus to implement parallel transactions | |
| US5561794A (en) | Early commit optimistic projection-based computer database protocol | |
| US8239635B2 (en) | System and method for performing visible and semi-visible read operations in a software transactional memory | |
| US8302105B2 (en) | Bulk synchronization in transactional memory systems | |
| JPH056297A (en) | Method of transaction processing and system | |
| US7548919B2 (en) | Computer program product for conducting a lock free read | |
| CN110675255B (en) | Method and apparatus for concurrently executing transactions in a blockchain | |
| CN110515707B (en) | Deterministic concurrency control method and system based on advanced transaction processing | |
| Hirve et al. | Archie: a speculative replicated transactional system | |
| CN109947742B (en) | Multi-version database concurrency control method and system for two-stage lock | |
| CN110955672B (en) | Multi-version support method and system for optimistic concurrency control | |
| CN112100188A (en) | Concurrent control method and system based on machine learning | |
| CN110689344B (en) | Method and apparatus for concurrently executing transactions in a blockchain | |
| CN115629822B (en) | Concurrent transaction processing method and system based on multi-core processor | |
| US5524239A (en) | Replay recovery protocol for real-time database management systems | |
| US7523088B2 (en) | Method for increasing system resource availability in database management systems | |
| CN115080670A (en) | Deterministic transaction concurrency control method based on GPU acceleration | |
| CN113505114A (en) | Multi-version concurrency control method of database and database system | |
| CN110865874B (en) | Transaction commit method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |