CN107391539A - Transaction methods, server and storage medium - Google Patents
Transaction methods, server and storage medium Download PDFInfo
- Publication number
- CN107391539A CN107391539A CN201710292017.2A CN201710292017A CN107391539A CN 107391539 A CN107391539 A CN 107391539A CN 201710292017 A CN201710292017 A CN 201710292017A CN 107391539 A CN107391539 A CN 107391539A
- Authority
- CN
- China
- Prior art keywords
- thread
- database
- operation instruction
- transaction
- database operation
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 64
- 238000003672 processing method Methods 0.000 claims description 12
- 238000004590 computer program Methods 0.000 claims description 10
- 238000011022 operating instruction Methods 0.000 abstract 8
- 230000008569 process Effects 0.000 description 38
- 238000005192 partition Methods 0.000 description 10
- 230000006872 improvement Effects 0.000 description 8
- 230000006870 function Effects 0.000 description 6
- 238000013508 migration Methods 0.000 description 6
- 230000005012 migration Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 5
- 238000012545 processing Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 238000003780 insertion Methods 0.000 description 2
- 230000037431 insertion Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
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/21—Design, administration or maintenance of databases
- G06F16/214—Database migration support
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Data Mining & Analysis (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The embodiment of the present application discloses a kind of transaction methods, server and storage medium.Methods described includes：It is provided with first thread and the second thread；Wherein, the first thread is opened in primary database the first affairs；First affairs include at least one database operating instruction；Second thread from database open have the second affairs；For each database operating instruction, the first thread performs the database operating instruction, and sends the database operating instruction to second thread；Second thread receives the database operating instruction, performs and using the database operating instruction as the database operating instruction in second affairs；After completion at least one database operating instruction is performed, the first thread submits first affairs to the primary database, and sends affairs to second thread and submit instruction；Second thread receives the affairs and submits instruction, and submits second affairs from database to described.
Description
Technical Field
The present application relates to the field of database technologies, and in particular, to a transaction processing method, a server, and a storage medium.
Background
A transaction may include one or more database operation instructions. Transactions are typically atomic. That is, one or more database operation instructions in a transaction as a whole are either all executed successfully or rolled back to an all unexecuted state.
Generally, due to the continuous change of business requirements, when an old database cannot support a new business requirement, data in the old database needs to be migrated to a new database to provide business services by using the new database instead of the old database. For example, data in the Oracle database is migrated to the MySQL database to provide business services using the MySQL database instead of the Oracle database. How to smoothly migrate data in an old database to a new database without influencing the provided business service is a problem to be considered in the database migration process.
One database migration method in the prior art is the "double write" method. That is, the server executes the same one or more write operation commands on the master database and the slave database respectively, so that the data in the master database and the slave database are consistent, and a developer can conveniently verify the correctness and reliability of the master database or the slave database. The master database can be a database for storing data and providing business services; the slave database may be a database for storing data but not providing business services. In particular, the master database may be an old database and the slave database may be a new database. Of course, the master database may be a new database, and the slave database may be an old database.
Specifically, after receiving a service request from a client, a server may parse the service request into one or more database operation instructions; a first transaction may be opened at a master database; the parsed one or more database operation instructions may be used as the database operation instructions in the first transaction; the analyzed one or more database operation instructions can be executed, wherein in the executing process, after the executed database operation instruction is identified as a write operation instruction, the database operation instruction can be recorded; the first transaction may be committed to the master database after executing the one or more database operation instructions that complete the parsing.
After committing the first transaction to the master database, the server may open a second transaction from the database; the recorded database operation instruction can be used as the database operation instruction in the second transaction; the recorded database operation instructions can be executed; the second transaction may be committed to the slave database after executing the database operation instruction that completes the record.
In the process of implementing the present application, the inventor finds that at least the following problems exist in the prior art:
in the prior art, the server needs to first open a first transaction in the master database; executing a database operation instruction in the first transaction; submitting the first transaction to a master database after the database operation instruction in the first transaction is executed; then opening a second transaction from the database; executing a database operation instruction in the second transaction; after the database operation instruction in the second transaction is completed, submitting the second transaction to the slave database so as to keep the data in the master database and the slave database consistent. In this way, a longer time interval may be generated between the time when the server submits the first transaction to the master database and the time when the server submits the second transaction to the slave database, so that a longer time interval may be generated between the database operation command in the first transaction at the time of the database drop of the master database and the database operation command in the second transaction at the time of the database drop of the slave database. Such a long time interval is not conducive to database migration and may even result in erroneous business results.
Disclosure of Invention
An object of the embodiments of the present application is to provide a transaction processing method, a server and a storage medium, so as to reduce a time interval between a time when the server submits a first transaction to a master database and a time when the server submits a second transaction to a slave database.
To achieve the above object, an embodiment of the present application provides a transaction processing method. The method is provided with a first thread and a second thread; the first thread opens a first transaction in a main database; the first transaction comprises at least one database operation instruction; the second thread has a second transaction open from the database. The method comprises the following steps: for each database operation instruction, the first thread executes the database operation instruction and sends the database operation instruction to the second thread; the second thread receives the database operation instruction, executes the database operation instruction and takes the database operation instruction as the database operation instruction in the second transaction; the first thread submits the first transaction to a master database and sends a transaction commit instruction to the second thread; the second thread receives the transaction commit instruction and commits the second transaction to a slave database.
To achieve the above object, an embodiment of the present application provides a server. The server is provided with a first thread and a second thread; the first thread opens a first transaction in a main database; the first transaction comprises at least one database operation instruction; the second thread has a second transaction open from the database. The server comprises a memory and a processor; wherein the memory is to store computer program instructions; the processor to read the computer program instructions; for each database operation instruction, the first thread executes the database operation instruction and sends the database operation instruction to the second thread; the second thread receives the database operation instruction, executes the database operation instruction and takes the database operation instruction as the database operation instruction in the second transaction; the first thread submits the first transaction to a master database and sends a transaction commit instruction to the second thread; the second thread receives the transaction commit instruction and commits the second transaction to a slave database.
To achieve the above object, an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored, and the computer program, when executed by a processor, implements the following steps: providing a first thread and a second thread; the first thread opens a first transaction in a main database; the first transaction comprises at least one database operation instruction; the second thread opens a second transaction from the database; for each database operation instruction, the first thread executes the database operation instruction and sends the database operation instruction to the second thread; the second thread receives the database operation instruction, executes the database operation instruction and takes the database operation instruction as the database operation instruction in the second transaction; the first thread submits the first transaction to a master database and sends a transaction commit instruction to the second thread; the second thread receives the transaction commit instruction and commits the second transaction to a slave database.
As can be seen from the above technical solutions provided by the embodiments of the present application, a server according to the embodiments of the present application may be provided with a first thread and a second thread, where the first thread may open a first transaction on a master database, the first transaction includes at least one database operation instruction, and the second thread may open a second transaction on a slave database; for each database operation instruction, the first thread may execute the database operation instruction and may send the database operation instruction to the second thread; the second thread may receive the database operation instruction, may execute and use the database operation instruction as the database operation instruction in the second transaction; after executing the at least one database operation instruction, the first thread may commit the first transaction to the master database and may send a transaction commit instruction to the second thread; the second thread may receive the transaction commit instruction and may commit the second transaction to the slave database. Compared with the prior art, the first thread can execute the database operation instruction in the second transaction in parallel during the process of executing the database operation instruction in the first transaction, so that the second transaction can be submitted to a slave database in a shorter time interval after the first transaction is submitted to a master database by the first thread. Thus, the server may reduce the time interval between the time of committing the first transaction to the master database and the time of committing the second transaction to the slave database compared to the prior art.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, it is obvious that the drawings in the following description are only some embodiments described in the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without any creative effort.
FIG. 1 is a diagram illustrating a prior art "double write" to a master database and a slave database;
FIG. 2 is a diagram illustrating a transaction processing method according to an embodiment of the present application;
FIG. 3 is a diagram illustrating a transaction processing method according to an embodiment of the present application;
FIG. 4 is a flow chart of a transaction processing method according to an embodiment of the present application;
FIG. 5 is a diagram illustrating a transaction processing method according to an embodiment of the present application;
fig. 6 is a functional structure diagram of a server according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
A typical database migration process in the prior art described above is described below.
The developer may use the old database as a master database, may use the new database as a slave database, and may divide the data in the old database into 3 partitions of Zone1, Zone2, Zone3, and the like.
The developer may migrate the data in Zone1 partition to a new database. During a first preset time period, the server may perform "double write" to the master database and the slave database for a write operation instruction pointing to data in the Zone1 partition; that is, the server may execute the write operation instruction on the master database and the slave database respectively, so as to keep the data in the master database and the slave database consistent, and facilitate the developer to verify the correctness and reliability of the new database. The time length of the first preset time period can be flexibly set according to actual needs, and for example, the time length can be 5 days, 7 days, or 9 days.
After passing the verification for the first preset time period, the developer may then migrate the data in Zone2 partition to the new database. Similar to the first preset time period, during the second preset time period, the server may "double write" the master database and the slave database for the write operation instruction pointing to the data in the Zone1 partition and the Zone2 partition; that is, the server may perform the write operation instruction at the master database and the slave database, respectively. The time length of the second preset time period can be flexibly set according to actual needs, and for example, the time length can be 5 days, 7 days, 10 days, or the like. The time lengths of the second preset time period and the first preset time period may be the same or different.
After passing the verification of the second preset time period, the developer can consider that the correctness and the reliability of the new database can meet the business requirements. In this manner, the developer can switch between the master database and the slave database. That is, the developer may have the new database as the master database and the old database as the slave database.
The developer may then migrate the data in Zone3 partition to the new database. Similar to the first preset time period, during the third preset time period, the server may perform "double write" to the master database and the slave database for the write operation instruction pointing to the data in the Zone1 partition, the Zone2 partition, and the Zone3 partition; that is, the server may perform the write operation instruction at the master database and the slave database, respectively. The time length of the third preset time period may be flexibly set according to actual needs, and may be, for example, 5 days, 7 days, or 11 days. The time lengths of the third preset time period and the first preset time period may be the same or different.
After the first preset time period, the second preset time period and the third preset time period, the developer can realize the migration of the data in the old database to the new database.
In the prior art, a typical "double write" process for the master database and the slave database may be as shown in fig. 1. The server may be provided with a business thread. The business thread may receive a business request from a client and may parse the business request into one or more database operation instructions.
After receiving a service request from a client, the service thread may open a first transaction in a main database; the parsed one or more database operation instructions may be used as the database operation instructions in the first transaction; the analyzed one or more database operation instructions can be executed, wherein in the executing process, after the executed database operation instruction is identified as a write operation instruction, the database operation instruction can be recorded; the first transaction may be committed to the master database after executing the one or more database operation instructions that complete the parsing.
After submitting the first transaction to the master database, the business thread may open a second transaction from the database; the recorded database operation instruction can be used as the database operation instruction in the second transaction; the recorded database operation instructions can be executed; the second transaction may be committed to the slave database after executing the database operation instruction that completes the record.
Thus, in the above-mentioned process of "double-writing" the master database and the slave database, the server is sequentially implemented by using a single business thread, and the processes of opening a first transaction in the master database, executing a database operation instruction in the first transaction, submitting the first transaction to the master database, opening a second transaction in the slave database, executing a database operation instruction in the second transaction, submitting the second transaction to the slave database, and the like are performed. In this way, a longer time interval may be generated between the time when the server submits the first transaction to the master database and the time when the server submits the second transaction to the slave database, so that a longer time interval may be generated between the database operation command in the first transaction at the time of the database drop of the master database and the database operation command in the second transaction at the time of the database drop of the slave database. Such a long time interval is not conducive to database migration and may even result in erroneous business results.
For example, the master database may include mobile phone credit balance DATA1 of zhang, and correspondingly, the slave database may also include mobile phone credit balance DATA1 of zhang. The database operation command in the first transaction can be used for modifying the mobile phone credit balance DATA1 of Zhang III in the main database into DATA2, and correspondingly, the database operation command in the second transaction can be used for modifying the mobile phone credit balance DATA1 of Zhang III in the auxiliary database into DATA 2.
And in the time interval between the business thread submitting the first transaction to the master database and the second transaction to the slave database, the mobile phone charge balance of Zhang III in the master database is DATA2, and the mobile phone charge balance of Zhang III in the slave database is DATA 1. That is, in the time interval, the balance of the mobile phone charge of Zhang III in the master database is inconsistent with the balance of the mobile phone charge of Zhang III in the slave database.
In some cases, the service thread may receive a service request from the client to obtain the charge balance of zhang san mobile phone during the time interval. Then, the charge balance of the mobile phone with the third address acquired from the main database by the service thread is inconsistent with the charge balance of the mobile phone with the third address acquired from the database, so that an error service result may be returned to the client.
Please refer to fig. 2, fig. 3, fig. 4, and fig. 5. The embodiment of the application provides a transaction processing method. The transaction processing method may be applied to a server. The server may be one server or a server cluster including a plurality of servers.
In this embodiment, the server may provide the first thread. Specifically, the server may have a business system application installed thereon. The business system application may start the first thread after being started.
In this embodiment, the first thread may be configured to receive a service request from a client. Specifically, the client may send a service request to the server, where the service request may carry service parameters. The first thread may receive the service request. The client may be, for example, a mobile smartphone, a tablet electronic device, a portable computer, a Personal Digital Assistant (PDA), an industrial personal computer, a Personal Computer (PC), or the like. The service request can be, for example, a telephone charge recharging request, a transfer request, a user information query request, or the like, and the service parameters can be, for example, a mobile phone number, an amount to be recharged, an account to be transferred, an amount to be transferred, or the like. The thread (thread), also called a Lightweight Process (LWP), is a single sequential control flow in a Process (Process) and can be the smallest unit of program execution. The server may generally use a process as a basic unit for allocating resources, and may use a thread as a basic unit for independent operation and independent scheduling. Threads may be executed concurrently, e.g., multiple threads in one process may be executed concurrently, and multiple threads in different processes may also be executed concurrently.
In this embodiment, the server may also provide a second thread. The second thread may be affiliated with the same process as the first thread or affiliated with a different process. Specifically, as described above, the server may have a business system application installed thereon. Thus, the second thread can be started after the business system application program is started. Of course, the server may also open the second thread in other manners. For example, the server may start the second thread after the first thread receives a service request from a client.
In this embodiment, the first thread may open a first transaction at a master database. The master database may be a database for storing data and providing business services. The main database can be an old database or a new database. For example, the master database may be an Oracle database or a MySQL database. The master database may be located at a server that performs embodiments of the present application. Of course, the master database may also be located in other servers.
In this embodiment, the server may store a transaction template of a master database. After receiving a service request from a client, the first thread may open a transaction in a master database based on a transaction template of the master database; and may take the transaction opened in the master database as the first transaction. Wherein, the transaction template of the database can be understood as an interface of the database for access. Such as an API (Application Programming Interface) Interface, etc. Opening a transaction in a database may be understood as establishing a session with the database. Thus, the transaction template of the master database may be understood as an interface of the master database. The first thread may establish a session with a master database based on an interface of the master database.
In this embodiment, after receiving a service request from a client, the first thread may parse the service request into one or more database operation instructions; the parsed database operation instruction may be used as the database operation instruction in the first transaction. Thus, the first transaction may include at least one database operation instruction.
In this embodiment, the database operation instruction may be an SQL database operation instruction. The SQL database operation instruction may include an SQL instruction identifier, an instruction parameter, a business parameter, and the like. The SQL instruction identifier may be, for example, SELECT, INSERT, delete, UPDATE, or the like. The instruction parameters may include, for example, a field identifier, a data table identifier, and the like, where the field identifier may be, for example, a name or a code of a field; the data table identifier may be, for example, an identifier or a code of the data table. The service parameter may be a service parameter carried in the service request, and specifically may be, for example, a mobile phone number, an amount to be recharged, an account to be transferred, an amount to be transferred, and the like. For example, the SQL database operation command SELECT 1FROM table1WHERE field2 is zhang, may include an SQL command identifier SELECT, may include command parameters field1, field2, and table1, and may include service parameters zhang.
Of course, the database operation instruction may be other operation instructions. For example, an operation instruction that performs a mathematical operation on the result of an SQL database operation instruction.
In this embodiment, for example, the service request may be a service request for charging the telephone fee to the mobile phone number zhang san, and the service request may carry service parameters such as the mobile phone number zhang san and the amount of money to be charged.
Then the first thread may parse the service request into database operation instruction a, database operation instruction B, and database operation instruction C. The database operation instruction a may be, for example, SELECT field1 finite 1WHERE field2 zhang san, and is used to read the telephone charge balance of zhang san mobile phone number from the database; the database operation instruction B can be used for carrying out addition operation on the read telephone charge balance and the amount to be recharged; the database operation instruction C may be, for example, UPDATE table1SET field1 XXX WHERE field2 zhang, for writing the result of the database operation instruction B back to the database.
In this embodiment, the second thread may be opening a second transaction from the database. The slave database may be a database for storing data but not providing business services. The slave database can be an old database or a new database. For example, the slave database may be an Oracle database or a MySQL database. The slave database may be located at a server that performs embodiments of the present application. Of course, the slave database may also be located in other servers. The slave database and the master database may be located in the same server or in different servers.
In this embodiment, the server may store transaction templates from a database. The first thread may send a transaction open instruction, which may be, for example, a TX-START instruction, to the second thread before or after opening the first transaction. The second thread may receive the transaction open instruction; a transaction may be started in the slave database based on the transaction template of the slave database; and may take the transaction that was started in the slave database as the second transaction. Wherein, the transaction template of the slave database can be understood as an interface of the slave database. The second thread may establish a session with the slave database based on an interface of the slave database.
In an implementation manner of this embodiment, the first thread and the second thread may share a global variable. As such, the first thread may assign the transaction open instruction to the global variable. The second thread may read a value of the global variable. Thus, this embodiment may implement that the first thread sends a transaction open instruction to the second thread, and the second thread receives the transaction open instruction.
In another implementation of this embodiment, the second thread may correspond to a message queue. As such, the first thread may write the transaction open instruction to the message queue. The second thread may monitor the message queue and may retrieve instructions from the message queue after monitoring that there are instructions in the message queue. Therefore, the second thread may read the transaction start instruction from the first thread from the message queue, and further, this embodiment may implement that the first thread sends the transaction start instruction to the second thread, and the second thread receives the transaction start instruction.
In this embodiment, the transaction processing method may include the following steps.
Step S11: for each database operation instruction in the first transaction, the first thread executes the database operation instruction.
In this embodiment, executing the database operation instruction in the transaction may be understood as obtaining and caching an operation result of the database operation instruction in the transaction.
In this embodiment, the first transaction may include at least one database operation instruction. In this way, for each database operation instruction, the first thread may execute the database operation instruction to obtain and cache an execution result of the database operation instruction. For example, the first thread may execute the database operation instruction SELECT field1 finite 1WHERE field2 zhang.
Step S12: the first thread sends the database operation instruction to the second thread, and the second thread receives the database operation instruction.
In this embodiment, the first thread may send the database operation instruction to the second thread before or after executing the database operation instruction.
In this embodiment, a process in which the first thread sends a database operation instruction to the second thread and the second thread receives the database operation instruction may be similar to the process in which the first thread sends a transaction start instruction to the second thread and the second thread receives the transaction start instruction.
Step S13: and the second thread executes and takes the database operation instruction as the database operation instruction in the second transaction.
In this embodiment, the second thread may execute a database operation instruction, and may use the database operation instruction as the database operation instruction in the second transaction. Thus, the second transaction may include at least one database operation instruction.
Step S14: after executing the database operation instruction in the first transaction, the first thread submits the first transaction to a master database.
In this embodiment, submitting a transaction to a database may be understood as writing an operation result of a database operation instruction in the transaction into the database, so as to modify, insert, delete, or the like data in the database. Thus, after the database operation instruction in the first transaction is completed, the first thread may submit the first transaction to the master database to modify, insert, delete, or the like data in the master database.
Step S15: the first thread sends a transaction commit instruction to the second thread, and the second thread receives the transaction commit instruction.
In this embodiment, the first thread may send a transaction COMMIT instruction, which may be, for example, TX-COMMIT, to the second thread after committing the first transaction to the master database.
In this embodiment, a process in which the first thread sends a transaction commit instruction to the second thread and the second thread receives the transaction commit instruction may be similar to the process in which the first thread sends a transaction open instruction to the second thread and the second thread receives the transaction open instruction.
Step S16: the second thread commits the second transaction to a slave database.
In this embodiment, the process of committing the second transaction to the slave database by the second thread may be similar to the process of committing the first transaction to the master database by the first thread described above.
In an implementation manner of this embodiment, for each database operation instruction in the first transaction, the first thread may further determine whether the database operation instruction is a write operation instruction; the database operation instruction can be sent to the second thread under the condition that the database operation instruction is determined to be a write operation instruction; the database operation instruction may not have to be sent to the second thread on a condition that the database operation instruction is determined not to be a write operation instruction.
In this manner, the first thread may send write operation instructions in the first transaction to the second thread without having to send respective database operation instructions in the first transaction to the second thread. Therefore, the present embodiment can reduce the number of times of communication between the first thread and the second thread, and can increase the processing speed of the server for the first transaction and the second transaction.
In this embodiment, as described above, the database operation instruction may include an SQL database operation instruction, and the SQL database operation instruction may include an SQL instruction identifier. In this way, the first thread may determine whether the database operation instruction is a write operation instruction according to the SQL instruction identifier of the database operation instruction. Specifically, for example, when the SQL instruction of the database operation instruction is identified as INSERT, delete, or UPDATE, the first thread may determine that the database operation instruction is a write operation instruction.
In one embodiment of the present embodiment, there may be inconsistency between the data in the master database and the data in the slave database, and such inconsistency may cause erroneous business results. For example, in a case where the first thread successfully submits the first transaction to the master database and the second thread fails to submit the second transaction to the slave database, there may be inconsistency between the data in the master database and the data in the slave database.
In order to identify whether the data pointed to by the database operation instruction in the master database is consistent with the data pointed to by the slave database before executing one database operation instruction, and avoid generation of a wrong service result, in the embodiment, for each database operation instruction in the first transaction, the first thread may acquire the data pointed to by the database operation instruction in the master database; the acquired data may be taken as first data; a data obtaining request may be sent to the second thread, where the data obtaining request may carry the database operation instruction. The second thread may receive the data fetch request; the data pointed by the database operation instruction in the slave database can be acquired; the acquired data may be taken as the second data.
Thus, under the condition that the first data and the second data are the same, the first thread can execute the database operation instruction in the first transaction; under the condition that the first data and the second data are not the same, the database operation instruction in the first transaction does not need to be executed, or prompt information and error information can be returned to the client.
In this embodiment, the data pointed to by the database operation instruction in the database may be understood as the data in the database for which the database operation instruction is executed. For example, one database operation may be an SQL database operation. As mentioned above, the SQL database operation instruction may include instruction parameters, business parameters, and the like. Then, the data in the database for which the database operation instruction is executed can be obtained according to the instruction parameter and the service parameter of the database operation instruction; the acquired data may be used as the data pointed to by the database operation instruction in the database. Specifically, for example, the database operation command SELECT field1FROM table1WHERE field2 is zhansan, which may include command parameters field1, field2, and table1, and business parameter zhansan. Then, the data in the database for which the database operation instruction is executed may be obtained according to the instruction parameters field1, field2, and table1, and the service parameter zhang, i.e., the value of the field2 field in the data table1 is the value of the zhang time field1 field; the acquired data may be used as the data pointed to by the database operation instruction in the database. Thus, in this embodiment, the first thread may obtain the first data pointed to by the database operation instruction in the master database according to the instruction parameter and the business parameter of the database operation instruction. Similarly, the second thread may obtain second data pointed by the database operation instruction in the slave database according to the instruction parameter and the service parameter of the database operation instruction.
In this embodiment, the first thread may send, to the second thread, an identifier used to indicate a data acquisition request and a database operation instruction carried in the data acquisition request, where the identifier used to indicate the data acquisition request may be, for example, TX-OBTAIN. The second thread may receive the identifier indicating the data obtaining request and a database operation instruction carried in the data obtaining request. Thus, this embodiment may enable the first thread to send a data acquisition request to the second thread, which receives the data acquisition request.
The process that the first thread sends the identifier used for representing the data acquisition request and the database operation instruction carried in the data acquisition request to the second thread, and the second thread receives the identifier used for representing the data acquisition request and the database operation instruction carried in the data acquisition request may be similar to the process that the first thread sends the transaction start instruction to the second thread and the second thread receives the transaction start instruction.
In this embodiment, the second thread may send the second data to the first thread. The first thread may receive the second data, and may compare the first data with the second data to determine whether the first data and the second data are the same.
The process of the second thread sending the second data to the first thread and the process of the second thread receiving the second data may be similar to the process of the first thread sending a transaction open instruction to the second thread and the process of the second thread receiving the transaction open instruction.
Alternatively, in this embodiment, the first thread may send the first data to the second thread. The second thread may receive the first data, and may compare the first data with the second data to determine whether the first data and the second data are the same.
Under the condition that the first data and the second data are the same, the second thread may send an identifier indicating that the first data and the second data are the same to the first thread, and the identifier indicating that the first data and the second data are the same may be, for example, TX-EQUAL _ YES. The first thread may receive the identifier indicating that the first data and the second data are the same, and may perform subsequent steps, e.g., may execute the database operation instruction in the first transaction.
Under the condition that the first data and the second data are not the same, the second thread may send, to the first thread, an identifier indicating that the first data and the second data are not the same, where the identifier indicating that the first data and the second data are not the same may be, for example, TX-EQUAL _ NO. The first thread may receive the identifier indicating that the first data and the second data are not the same, may not have to perform subsequent steps, e.g., may not have to execute the database operation instruction in the first transaction, or may return a hint and an error to the client.
The process of the first thread sending the first data to the second thread and the second thread receiving the first data may be similar to the process of the first thread sending a transaction open instruction to the second thread and the second thread receiving the transaction open instruction. The process of the second thread sending the identifier indicating that the first data is the same as the second data to the first thread, and the process of the first thread receiving the identifier indicating that the first data is the same as the second data to the first thread may be similar to the process of the first thread sending a transaction open instruction to the second thread and the process of the second thread receiving the transaction open instruction. The sending, by the second thread, the identifier indicating that the first data is different from the second data to the first thread, and the receiving, by the first thread, the identifier indicating that the first data is different from the second data may be similar to the sending, by the first thread, the transaction open instruction to the second thread, and the receiving, by the second thread, the transaction open instruction.
Further, in this embodiment, each database operation instruction may have a type identifier, where the type identifier may be used to represent operation content corresponding to the database operation instruction, and the operation content may specifically include an operation type and an operation field of the database operation instruction. The operation type of the database operation instruction may be, for example, lookup, insertion, deletion, update, etc., and the operation field of the database operation instruction may be, for example, field1, field2, etc.
In particular, as previously described, the database operation instructions may include SQL database operation instructions, which may include SQL instruction identifications. In this way, the operation type of the database operation instruction can be determined according to the SQL instruction identifier of the database operation instruction. Specifically, for example, when the SQL instruction identifier of the database operation instruction is SELECT, it may be determined that the operation type of the database operation instruction is search; when the SQL instruction of the database operation instruction is identified as INSERT, determining that the operation type of the database operation instruction is insertion; when the SQL instruction of the database operation instruction is identified as DELECT, determining that the operation type of the database operation instruction is deletion; when the SQL instruction of the database operation instruction is identified as UPDATE, the operation type of the database operation instruction may be determined to be UPDATE.
Specifically, as mentioned above, the database operation instruction may include an SQL database operation instruction, which may include instruction parameters, which may include, for example, a field identifier, a data table identifier, and the like. In this way, the operation field of the database operation instruction can be determined according to the instruction parameter of the database operation instruction.
For example, the database operation instruction SELECT field1FROM table1WHERE field2 is zhang san, the operation type may be lookup, and the operation field may be field 1. The database operation instruction SELECT field1 finite 1WHERE field2 ═ lie four, the operation type may be a lookup, and the operation field may be field 1. The database operation command UPDATE table1SET field1 XXX WHERE field2 zhang san, whose operation type may be UPDATE, and whose operation field may be field 1. The database operation instruction SELECT field3FROM table1WHERE field2 is zhang san, the operation type may be lookup, and the operation field may be field 3.
Then, the database OPERATION command SELECT field1FROM table1WHERE field2 is zhang three and the database OPERATION command SELECT field1FROM table1WHERE field2 is liquad may have the same type identifier OPERATION 1. The database OPERATION command UPDATE table1SET field1 XXX WHERE field2 zhang san, whose type identifier may be OPERATION 2. The database OPERATION instruction SELECT field3FROM table1WHERE field2 is zhang san, and the type identifier may be OPERATION 3.
In this embodiment, the server may provide a set of identities. The set of identifications may include an identification of a type of the at least one database operation instruction. The database operation instruction corresponding to the type identifier in the identifier set may be a preset database operation instruction requiring data comparison, that is, first data to which the database operation instruction points in the master database may be compared with second data to which the database operation instruction points in the slave database. Specifically, for example, the database operation instruction corresponding to the type identifier in the identifier set may include a database operation instruction for searching a call charge balance, and a database operation instruction for updating an account balance.
As such, in this embodiment, for each database operation instruction in the first transaction, the first thread may further match the type identifier of the database operation instruction in the identifier set. For example, the first thread may find whether the type identifier of the database operation instruction is included in the identifier set.
Under the condition that the type identifier of the database operation instruction is matched in the identifier set, the first thread may obtain first data pointed by the database operation instruction in the master database, so as to implement comparison of the first data pointed by the database operation instruction in the master database with second data pointed by the database operation instruction in the slave database.
Under the condition that the type identifier of the database operation instruction is not matched in the type identifier set, the first thread may not need to acquire the first data pointed by the database operation instruction in the main database, and may directly execute the database operation instruction.
The implementation method can avoid comparing each database operation instruction in the first transaction, the first data pointed to in the master database and the second data pointed to in the slave database; the data acquisition times and comparison times can be reduced; the processing speed of the server for the first transaction and the second transaction can be improved.
Further, in this embodiment, the database may generally have a Lock (Lock) mechanism to prevent database operation instructions in different transactions from operating on the same data at the same time. The lock implementing the locking mechanism may be a read lock, a write lock, or a row lock, etc. In particular, each data in the database may correspond to a tag, which may be, for example, a variable, for indicating whether the data is in a locked state. For example, when a database operation instruction in a transaction operates on the data, the value of the tag corresponding to the data may be set to 1, so as to indicate that the data is in a locked state; when the transaction is committed to the database, the value of the tag corresponding to the data may be set to 0 to indicate that the data is not in a locked state.
As such, for each database operation instruction in the first transaction, the first thread may further identify whether the first data pointed to by the database operation instruction in the master database is in a locked state. For example, the first thread may identify whether the first data is in a locked state according to a value of a tag corresponding to the first data.
Under the condition that the first data is identified to be unlocked, the first thread can acquire the first data pointed by the database operation instruction in the master database so as to compare the first data pointed by the database operation instruction in the master database with the second data pointed by the database operation instruction in the slave database.
Under the condition of identifying that the first data is in a locked state, the first thread may consider that the database operation instruction does not need to perform data comparison, that is, the first data pointed by the database operation instruction in the master database does not need to be compared with the second data pointed by the database operation instruction in the slave database. Thus, the first thread may not necessarily acquire the first data pointed to by the database operation instruction in the master database, but may directly execute the database operation instruction.
The implementation method can avoid comparing each database operation instruction in the first transaction, the first data pointed to in the master database and the second data pointed to in the slave database; the data acquisition times and comparison times can be reduced; the processing speed of the server for the first transaction and the second transaction can be improved.
In this embodiment, the server may be provided with a first thread and a second thread, wherein the first thread may open a first transaction on the master database, the first transaction includes at least one database operation instruction, and the second thread may open a second transaction on the slave database; for each database operation instruction, the first thread may execute the database operation instruction and may send the database operation instruction to the second thread; the second thread may receive the database operation instruction, may execute and use the database operation instruction as the database operation instruction in the second transaction; after executing the at least one database operation instruction, the first thread may commit the first transaction to the master database and may send a transaction commit instruction to the second thread; the second thread may receive the transaction commit instruction and may commit the second transaction to the slave database. Compared with the prior art, the second thread can execute the database operation instruction in the second transaction in parallel during the first thread executes the database operation instruction in the first transaction, so that after the first thread submits the first transaction to the master database, the second thread does not need to wait for the execution of the database operation instruction in the second transaction, and can submit the second transaction to the slave database in a shorter time interval. Thus, the server may reduce the time interval between the time of committing the first transaction to the master database and the time of committing the second transaction to the slave database compared to the prior art.
Please refer to fig. 6. The embodiment of the application also provides a server. The server may be provided with a first thread and a second thread; the first thread opens a first transaction in a main database; the first transaction comprises at least one database operation instruction; the second thread has a second transaction open from the database. The server may include a memory and a processor.
In this embodiment, the memory may be implemented in any suitable manner. For example, the memory may be a read-only memory, a mechanical hard disk, a solid state disk, a U disk, or the like.
In this embodiment, the memory may be used to store program instructions.
In this embodiment, the processor may be implemented in any suitable manner. For example, the processor may take the form of, for example, a microprocessor or processor and a computer-readable medium that stores computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, an embedded microcontroller, and so forth. The present application is not limited.
In this embodiment, the functions implemented by the processor by executing the program instructions include: for each database operation instruction, the first thread executes the database operation instruction and sends the database operation instruction to the second thread; the second thread receives the database operation instruction, executes the database operation instruction and takes the database operation instruction as the database operation instruction in the second transaction; the first thread submits the first transaction to a master database and sends a transaction commit instruction to the second thread; the second thread receives the transaction commit instruction and commits the second transaction to a slave database.
In this embodiment, the functions performed by the processor may be explained in comparison with the previous embodiments.
Embodiments of the present application also provide a computer-readable storage medium on which a computer program is stored.
In this embodiment, the computer program may implement the following steps when executed by a processor.
Providing a first thread and a second thread; the first thread opens a first transaction in a main database; the first transaction comprises at least one database operation instruction; the second thread opens a second transaction from the database;
for each database operation instruction, the first thread executes the database operation instruction and sends the database operation instruction to the second thread; the second thread receives the database operation instruction, executes the database operation instruction and takes the database operation instruction as the database operation instruction in the second transaction;
the first thread submits the first transaction to a master database and sends a transaction commit instruction to the second thread; the second thread receives the transaction commit instruction and commits the second transaction to a slave database.
In this embodiment, specific functions and methods implemented by the computer program may be explained in comparison with the foregoing embodiments, and are not described herein again.
In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate a dedicated integrated circuit chip 2. Furthermore, nowadays, instead of manually making an integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Language Description Language), traffic, pl (core unified Programming Language), HDCal, JHDL (Java Hardware Description Language), langue, Lola, HDL, laspam, hardsradware (Hardware Description Language), vhjhd (Hardware Description Language), and vhigh-Language, which are currently used in most popular applications. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
From the above description of the embodiments, it is clear to those skilled in the art that the present application can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the present application may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method according to the embodiments or some parts of the embodiments of the present application.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
The application is operational with numerous general purpose or special purpose computing system environments or configurations. For example: personal computers, server computers, hand-held or portable devices, tablet-type devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The application may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The application may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
While the present application has been described with examples, those of ordinary skill in the art will appreciate that there are numerous variations and permutations of the present application without departing from the spirit of the application, and it is intended that the appended claims encompass such variations and permutations without departing from the spirit of the application.
Claims (10)
1. A transaction processing method is provided with a first thread and a second thread; the first thread opens a first transaction in a main database; the first transaction comprises at least one database operation instruction; the second thread opens a second transaction from the database; the method comprises the following steps:
for each database operation instruction, the first thread executes the database operation instruction and sends the database operation instruction to the second thread; the second thread receives the database operation instruction, executes the database operation instruction and takes the database operation instruction as the database operation instruction in the second transaction;
the first thread submits the first transaction to a master database and sends a transaction commit instruction to the second thread; the second thread receives the transaction commit instruction and commits the second transaction to a slave database.
2. The method of claim 1, the second thread to open the second transaction as follows:
the first thread writes a transaction opening instruction into a message queue;
and the second thread reads the transaction opening instruction from the message queue and executes the transaction opening instruction.
3. The method of claim 1, the first thread sending the database operation instruction to the second thread, comprising:
and under the condition that the database operation instruction is a write operation instruction, the first thread sends the database operation instruction to the second thread.
4. The method of claim 1, the first thread sending the database operation instruction to the second thread, comprising:
the first thread writes the database operation instruction into a message queue;
accordingly, the second thread receives the database operation instruction, including:
and the second thread reads the database operation instruction from the message queue.
5. The method of claim 1, the first thread sending a transaction commit instruction to the second thread, comprising:
the first thread writes a transaction commit instruction into a message queue;
accordingly, the second thread receives the transaction commit instruction, including:
the second thread reads the transaction commit instruction from the message queue.
6. The method of claim 1, prior to the first thread executing the database operation instruction, the method further comprising:
the first thread acquires first data pointed by the database operation instruction in a main database and sends a data acquisition request to the second thread; the data acquisition request carries the database operation instruction; the second thread receives the data acquisition request and acquires second data pointed by the database operation instruction in the slave database;
accordingly, the first thread executes the database operation instruction, including:
and under the condition that the first data and the second data are the same, the first thread executes the database operation instruction.
7. The method of claim 6, wherein each database operation instruction corresponds to a type identifier; the type identification is used for representing operation content corresponding to the database operation instruction;
accordingly, before the first thread acquires the first data pointed to by the database operation instruction in the master database, the method further comprises:
the first thread matches the type identification of the database operation instruction in an identification set; wherein the set of identities comprises at least one type identity;
accordingly, the first thread acquires the first data pointed by the database operation instruction in the master database, and comprises:
and under the condition that the type identifier of the database operation instruction is matched in the identifier set, the first thread acquires first data pointed by the database operation instruction in a main database.
8. The method of claim 7, wherein the first thread obtaining the first data pointed to by the database operation instruction in the master database comprises:
and under the condition that the first data pointed by the database operation instruction in the master database is unlocked, the first thread acquires the first data pointed by the database operation instruction in the master database.
9. A server provided with a first thread and a second thread; the first thread opens a first transaction in a main database; the first transaction comprises at least one database operation instruction; the second thread opens a second transaction from the database; the server comprises a memory and a processor; wherein,
the memory to store computer program instructions;
the processor to read the computer program instructions; for each database operation instruction, the first thread executes the database operation instruction and sends the database operation instruction to the second thread; the second thread receives the database operation instruction, executes the database operation instruction and takes the database operation instruction as the database operation instruction in the second transaction; the first thread submits the first transaction to a master database and sends a transaction commit instruction to the second thread; the second thread receives the transaction commit instruction and commits the second transaction to a slave database.
10. A computer-readable storage medium, on which a computer program is stored which, when executed by a processor, carries out the steps of:
providing a first thread and a second thread; the first thread opens a first transaction in a main database; the first transaction comprises at least one database operation instruction; the second thread opens a second transaction from the database;
for each database operation instruction, the first thread executes the database operation instruction and sends the database operation instruction to the second thread; the second thread receives the database operation instruction, executes the database operation instruction and takes the database operation instruction as the database operation instruction in the second transaction;
the first thread submits the first transaction to a master database and sends a transaction commit instruction to the second thread; the second thread receives the transaction commit instruction and commits the second transaction to a slave database.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710292017.2A CN107391539B (en) | 2017-04-28 | 2017-04-28 | Transaction processing method, server and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710292017.2A CN107391539B (en) | 2017-04-28 | 2017-04-28 | Transaction processing method, server and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107391539A true CN107391539A (en) | 2017-11-24 |
| CN107391539B CN107391539B (en) | 2020-08-04 |
Family
ID=60338463
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710292017.2A Active CN107391539B (en) | 2017-04-28 | 2017-04-28 | Transaction processing method, server and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107391539B (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110196844A (en) * | 2018-04-16 | 2019-09-03 | 腾讯科技（深圳）有限公司 | A kind of data migration method, system and storage medium |
| CN110502317A (en) * | 2018-05-16 | 2019-11-26 | 北京京东尚科信息技术有限公司 | A kind of method and apparatus of transaction management |
| CN110750517A (en) * | 2019-10-12 | 2020-02-04 | 浪潮电子信息产业股份有限公司 | Data processing method, device and equipment of local storage engine system |
| CN114356559A (en) * | 2021-12-22 | 2022-04-15 | 青岛海信移动通信技术股份有限公司 | Multithreading control method and terminal equipment |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103856724A (en) * | 2012-12-05 | 2014-06-11 | 成都索贝数码科技股份有限公司 | Manufacturing emergency system |
| US9032017B1 (en) * | 2010-08-10 | 2015-05-12 | Scalarc Inc | Method and system for transparent read-write query routing when load balancing databases |
| CN104750755A (en) * | 2013-12-31 | 2015-07-01 | 阿里巴巴集团控股有限公司 | Method and system for recovering data after switching between main database and standby database |
| CN105373420A (en) * | 2014-08-28 | 2016-03-02 | 北京奇虎科技有限公司 | Data transmission method and apparatus |
| CN105824846A (en) * | 2015-01-09 | 2016-08-03 | 阿里巴巴集团控股有限公司 | Data migration method and device |
| CN106534226A (en) * | 2015-09-09 | 2017-03-22 | 阿里巴巴集团控股有限公司 | Processing method and apparatus for data migration |
-
2017
- 2017-04-28 CN CN201710292017.2A patent/CN107391539B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9032017B1 (en) * | 2010-08-10 | 2015-05-12 | Scalarc Inc | Method and system for transparent read-write query routing when load balancing databases |
| CN103856724A (en) * | 2012-12-05 | 2014-06-11 | 成都索贝数码科技股份有限公司 | Manufacturing emergency system |
| CN104750755A (en) * | 2013-12-31 | 2015-07-01 | 阿里巴巴集团控股有限公司 | Method and system for recovering data after switching between main database and standby database |
| CN105373420A (en) * | 2014-08-28 | 2016-03-02 | 北京奇虎科技有限公司 | Data transmission method and apparatus |
| CN105824846A (en) * | 2015-01-09 | 2016-08-03 | 阿里巴巴集团控股有限公司 | Data migration method and device |
| CN106534226A (en) * | 2015-09-09 | 2017-03-22 | 阿里巴巴集团控股有限公司 | Processing method and apparatus for data migration |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110196844A (en) * | 2018-04-16 | 2019-09-03 | 腾讯科技（深圳）有限公司 | A kind of data migration method, system and storage medium |
| CN110196844B (en) * | 2018-04-16 | 2024-01-30 | 腾讯科技（深圳）有限公司 | Data migration method, system and storage medium |
| CN110502317A (en) * | 2018-05-16 | 2019-11-26 | 北京京东尚科信息技术有限公司 | A kind of method and apparatus of transaction management |
| CN110502317B (en) * | 2018-05-16 | 2024-03-01 | 北京京东尚科信息技术有限公司 | Transaction management method and device |
| CN110750517A (en) * | 2019-10-12 | 2020-02-04 | 浪潮电子信息产业股份有限公司 | Data processing method, device and equipment of local storage engine system |
| CN110750517B (en) * | 2019-10-12 | 2022-06-10 | 浪潮电子信息产业股份有限公司 | Data processing method, device and equipment of local storage engine system |
| CN114356559A (en) * | 2021-12-22 | 2022-04-15 | 青岛海信移动通信技术股份有限公司 | Multithreading control method and terminal equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107391539B (en) | 2020-08-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110520837B (en) | Method, system, and medium for facilitating processing in a computing environment | |
| US11556396B2 (en) | Structure linked native query database management system and methods | |
| US11386065B2 (en) | Database concurrency control through hash-bucket latching | |
| US9990224B2 (en) | Relaxing transaction serializability with statement-based data replication | |
| US9021303B1 (en) | Multi-threaded in-memory processing of a transaction log for concurrent access to data during log replay | |
| US8671085B2 (en) | Consistent database recovery across constituent segments | |
| US10684966B1 (en) | Orchestrating dataflows with inferred data store interactions | |
| US10970311B2 (en) | Scalable snapshot isolation on non-transactional NoSQL | |
| US10255062B1 (en) | Optimized class loading | |
| CN107391539B (en) | Transaction processing method, server and storage medium | |
| CN108536745B (en) | Shell-based data table extraction method, terminal, equipment and storage medium | |
| US10394775B2 (en) | Order constraint for transaction processing with snapshot isolation on non-transactional NoSQL servers | |
| CN103999036A (en) | Method and system using exceptions for code specialization in a computer architecture that supports transactions | |
| US11907260B2 (en) | Compare processing using replication log-injected compare records in a replication environment | |
| US10817285B1 (en) | Transactional migration system | |
| CN114925084A (en) | Distributed transaction processing method, system, device and readable storage medium | |
| CN112970011B (en) | Pedigree in record query optimization | |
| US20190294205A1 (en) | Efficient timestamp solution for analyzing concurrent software systems | |
| US11853284B2 (en) | In-place updates with concurrent reads in a decomposed state | |
| US10127270B1 (en) | Transaction processing using a key-value store | |
| US10558502B2 (en) | Software application runtime having dynamic evaluation functions and parameters | |
| CN115113989B (en) | Transaction execution method, device, computing equipment and storage medium | |
| US11392562B2 (en) | Hybrid client transaction mode for key value store | |
| CN114756362A (en) | Resource quota management method and system, intelligent terminal and storage medium | |
| CN117539650B (en) | Decentralised record lock management method of data management system and related equipment |
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 | ||
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20201016 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Patentee after: Innovative advanced technology Co.,Ltd. Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Patentee before: Advanced innovation technology Co.,Ltd. Effective date of registration: 20201016 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Patentee after: Advanced innovation technology Co.,Ltd. Address before: Greater Cayman, British Cayman Islands Patentee before: Alibaba Group Holding Ltd. |