CN112363846B - Deadlock detection method and device for database transaction and electronic equipment - Google Patents
Deadlock detection method and device for database transaction and electronic equipment Download PDFInfo
- Publication number
- CN112363846B CN112363846B CN202110028189.5A CN202110028189A CN112363846B CN 112363846 B CN112363846 B CN 112363846B CN 202110028189 A CN202110028189 A CN 202110028189A CN 112363846 B CN112363846 B CN 112363846B
- Authority
- CN
- China
- Prior art keywords
- transaction
- deadlock
- target transaction
- deadlock detection
- target
- 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
- 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/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
- G06F9/524—Deadlock detection or avoidance
-
- 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)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention provides a deadlock detection method and device for database transactions and electronic equipment, and relates to the technical field of databases, wherein the method comprises the steps of judging whether a target transaction meets the preset necessary condition for deadlock occurrence or not if the target transaction is detected to be in a suspension state; wherein the target transaction is in a suspended state when the target transaction is blocked; deadlock detection is triggered if the target transaction satisfies the necessary conditions for deadlock to occur. The embodiment of the invention is used for eliminating the condition that a part of target transactions which are not possible to generate deadlock are suspended by setting the necessary condition for generating deadlock, and deadlock detection is carried out only when the necessary condition is met, thereby reducing the times of deadlock detection, improving the efficiency of deadlock detection, saving the CPU resource of a database system and improving the concurrent processing capacity of a lock system.
Description
Technical Field
The invention relates to the technical field of databases, in particular to a deadlock detection method and device for database transactions and electronic equipment.
Background
Deadlock detection is a costly task involving holding a lock system mutex, acquiring a transaction in a suspended state, constructing a transaction wait graph, calculating whether a ring appears, and releasing the lock system mutex.
In actual operation, deadlock detection is triggered as long as a background thread of the database lock system finds that a transaction is suspended. However, in practice, most transaction conflicts cannot be deadlock, and in the conventional database, the effective deadlock detection probability by the deadlock detection mode is about 3%, so that a great amount of deadlock detection is of no practical significance. Moreover, a large amount of deadlock detection not only consumes the CPU resource of the database system, but also reduces the concurrent processing capacity of the lock system and increases the response time of really needing deadlock detection because the deadlock detection holds the mutual exclusion lock of the lock system.
Overall, the deadlock detection mode of the existing database can cause a large amount of meaningless deadlock detection, waste the CPU resource of the database system, reduce the concurrent processing capability of the lock system, and have low deadlock detection efficiency.
Disclosure of Invention
In view of this, an object of the present invention is to provide a deadlock detection method and apparatus for a database transaction, and an electronic device, which can reduce the number of meaningless deadlock detections of a database lock system, improve deadlock detection efficiency, save CPU resources of the database system, and improve concurrent processing capability of the lock system.
In a first aspect, an embodiment of the present invention provides a deadlock detection method for a database transaction, including: if the target transaction is in a suspension state, judging whether the target transaction meets the preset necessary condition for deadlock occurrence; wherein the target transaction is in a suspended state when the target transaction is blocked; deadlock detection is triggered if the target transaction satisfies the necessary conditions for deadlock to occur.
In an optional embodiment of the present invention, the step of determining whether the target transaction meets a preset requirement for deadlock occurrence includes: detecting whether a first transaction blocking the target transaction is in a suspended state and whether a second transaction blocked by the target transaction exists; if a first transaction blocking the target transaction is in a pending state and there is a second transaction blocked by the target transaction, determining that the target transaction satisfies the necessary conditions for deadlock to occur.
In an optional embodiment of the present invention, the step of detecting whether there is a second transaction blocked by the target transaction includes: acquiring a counting value of a preset counting parameter, wherein the counting parameter is used for counting a second transaction blocked by the target transaction; and judging whether the count value is zero, and if not, determining that a second transaction blocked by the target transaction exists.
In an alternative embodiment of the present invention, the preset counting parameter is counted in an atomic increment manner.
In an optional embodiment of the present invention, the method further includes: if the count value is not zero, clearing the count value under the condition that the target transaction is detected to complete the submission.
In an optional embodiment of the present invention, the step of detecting whether the first transaction blocking the target transaction is in a suspended state includes: reading state information of a first transaction blocking the target transaction; and judging whether the first transaction is in a suspended state or not according to the state information.
In an optional embodiment of the present invention, after the step of triggering deadlock detection if a first transaction blocking the target transaction is in a suspended state and there is a second transaction blocked by the target transaction, the method further comprises: and if the deadlock detection result is that the deadlock exists, revoking the target transaction.
In a second aspect, an embodiment of the present invention further provides a deadlock detection apparatus for a database transaction, including: the necessary condition judging module is used for judging whether the target transaction meets the preset necessary condition for deadlock occurrence or not under the condition that the target transaction is in a suspended state; wherein the target transaction is in a suspended state when the target transaction is blocked; and the deadlock detection triggering module is used for triggering deadlock detection under the condition that the target transaction meets the necessary condition for deadlock occurrence.
In a third aspect, an embodiment of the present invention further provides an electronic device, where the electronic device includes a processor and a memory, where the memory stores computer-executable instructions that can be executed by the processor, and the processor executes the computer-executable instructions to implement the deadlock detection method for a database transaction.
In a fourth aspect, embodiments of the present invention also provide a computer-readable storage medium storing computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the deadlock detection method for a database transaction described above.
The embodiment of the invention has the following beneficial effects:
according to the deadlock detection method, the deadlock detection device and the electronic equipment for the database transaction provided by the embodiment of the invention, if the target transaction is detected to be in a suspension state, whether the target transaction meets the preset necessary condition for deadlock occurrence is judged; wherein the target transaction is in a suspended state when the target transaction is blocked; deadlock detection is triggered if the target transaction satisfies the necessary conditions for deadlock to occur. In the method, the necessary condition for deadlock occurrence is set, and deadlock detection is performed only when the necessary condition is met, so that the condition that a part of target transactions which are not possible to deadlock occurrence are suspended is eliminated, the times of deadlock detection are reduced, the efficiency of deadlock detection is improved, the CPU (Central processing Unit) resource of a database system is saved, and the concurrent processing capacity of a lock system is improved.
Additional features and advantages of the disclosure will be set forth in the description which follows, or in part may be learned by the practice of the above-described techniques of the disclosure, or may be learned by practice of the disclosure.
In order to make the aforementioned objects, features and advantages of the present disclosure more comprehensible, preferred embodiments accompanied with figures are described in detail below.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and other drawings can be obtained by those skilled in the art without creative efforts.
Fig. 1 is a schematic flowchart of a deadlock detection method for a database transaction according to an embodiment of the present invention;
FIG. 2 is a flowchart illustrating another deadlock detection method for a database transaction according to an embodiment of the present invention;
fig. 3 is a schematic structural diagram of a deadlock detection apparatus for a database transaction according to an embodiment of the present invention;
fig. 4 is a schematic structural diagram of an electronic device according to an embodiment of the present invention.
Icon: 31-a necessary condition judgment module; 32-deadlock detection trigger module; 41-a processor; 42-a memory; 43-bus; 44-communication interface.
Detailed Description
To make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings, and it is apparent that the described embodiments are some, but not all embodiments of the present invention. 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 invention.
Write collision is a common phenomenon of a database in an online Transaction Processing (OLTP), and in order to avoid deadlock in a Transaction write collision scenario, the database usually performs deadlock detection. The general flow of deadlock detection is as follows:
(1) holding the transaction level mutual exclusion lock of the transaction;
(2) judging whether the transaction conflicts with other transactions in a locking way;
(3) if conflict occurs, suspending the transaction and setting a suspended state;
(4) deadlock detection is carried out;
(5) and releasing the transaction level mutual exclusion lock of the transaction.
In consideration of the problem that deadlock detection efficiency is low due to a large amount of meaningless deadlock detection caused by a deadlock detection mode of the existing database, the deadlock detection method, the deadlock detection device and the electronic equipment for the database transaction provided by the embodiment of the invention can be applied to various application scenes needing deadlock detection. To facilitate understanding of the embodiment, first, a detailed description is given to a deadlock detection method for a database transaction disclosed in the embodiment of the present invention.
Referring to fig. 1, a flow chart of a deadlock detection method for a database transaction is shown, and as can be seen from fig. 1, the method includes the following steps:
step S102: if the target transaction is in a suspension state, judging whether the target transaction meets the preset necessary condition for deadlock occurrence; wherein the target transaction is in a suspended state when the target transaction is blocked.
In this embodiment, the dead lock detection method is applied to a database system, and is used for optimizing a lock system in the database system. For example, the lock system may be a subsystem of the MySQL Innodb storage engine for row locks, table locks. Also, the above-mentioned transaction refers to a program execution unit that accesses and possibly updates various data items in the database, which is a basic unit of recovery and concurrency control, and the transaction is generally composed of an overall operation performed between a transaction start (begin transaction) and a transaction end (end transaction).
Here, deadlock refers to a phenomenon that two or more transactions are blocked due to competing resources or due to communicating with each other during execution, and cannot advance without external force. At this time, the system is said to be in a deadlock state or the system is deadlock.
The necessary conditions for deadlock to occur may include:
(1) mutual exclusion condition: a transaction is exclusive to the allocated resource, i.e. a resource can only be occupied by a transaction until it is released by the transaction;
(2) occupation and waiting: when one transaction is blocked due to the fact that the transaction requests occupied resources, the acquired resources are kept unused;
(3) non-preemptive condition: before any resource is not released by the transaction, any other transaction cannot deprive the transaction of occupation;
(4) and (3) a cyclic waiting condition: when a deadlock occurs, the waiting transaction must form a loop (similar to a dead loop), causing a permanent block.
That is, deadlock occurs when the above four conditions are simultaneously satisfied. In actual operation, deadlock detection is triggered as long as a background thread of the database lock system finds that a transaction is suspended. However, in practice, most transaction conflicts will not be deadlocked, resulting in wasted detection resources.
In order to solve the problem that deadlock can not occur but deadlock detection is still performed, according to the deadlock detection scheme provided by the application, when a target transaction is detected to be in a suspended state, deadlock detection cannot be performed immediately, whether the target transaction meets a preset necessary condition for deadlock occurrence is judged first, and deadlock detection is started only when the preset necessary condition is met. The preset requirement for deadlock occurrence may be any one or more of the four requirements.
Step S104: deadlock detection is triggered if the target transaction satisfies the necessary conditions for deadlock to occur.
By setting the necessary condition for deadlock, judging the target transaction based on the necessary condition, screening the target transaction meeting the necessary condition, and triggering deadlock detection only when the target transaction meets the condition, the conditions that part of the target transaction cannot be deadlocked are screened out, the times of deadlock detection are reduced, the hit rate and efficiency of deadlock detection are improved, and system resources are saved.
In at least one possible implementation manner, the step of determining whether the target transaction satisfies the preset requirement for deadlock occurrence in step S102 may be implemented by the following steps 11 to 12:
(11) if it is detected that the target transaction is in a pending state, it is detected whether a first transaction blocking the target transaction is in a pending state and whether there is a second transaction blocked by the target transaction.
In one possible implementation, the following steps 21-23 may be followed to determine whether the target transaction needs to be suspended:
(21) and if a processing request of a user for the target transaction is received, allocating a corresponding processing thread for the target transaction.
(22) A mutual exclusion lock at the transaction level holding the target transaction.
Here, the mutex is a solution proposed to resolve conflicts generated by simultaneous operations on a shared resource by a plurality of threads when a plurality of threads access the shared resource. During execution, which thread holds the mutual exclusive lock and can only operate the shared resource after the shared resource is locked, and other threads cannot operate the shared resource at this time. And only after the thread holding the row lock unlocks and releases the row lock of the shared resource, other threads can carry out operation of rob-in-row lock and locking on the shared resource.
For example, in order for a transaction T1 to modify a record R1, T1 holds a row lock (with mutual exclusion) for R1 before T1 commits. At this point, assuming that another transaction T2 also modifies the record R1, T2 attempts to acquire the row lock of R1. If T1 has not committed at this time, T2 cannot acquire the row lock of R1, at which point the database suspends T2, i.e., T2 enters the suspend pending state. When T1 is committed, the database wakes up T2, and T2 gets the row lock of R1 and performs modifications and related follow-up work.
(23) Judging whether the target transaction has a lock conflict with database transactions in the database except the target transaction; if so, the target transaction is suspended.
Since each row may have a row lock (a mutually exclusive lock), when a transaction holds a row lock of a certain row, a row lock conflict may occur if another transaction also attempts to acquire the row lock of the certain row.
Here, if the target transaction has a lock conflict with other transactions in the database, it indicates that the lock of the target row that the target transaction attempts to acquire is occupied by other transactions, and it needs to wait for the lock of the target row to be released before acquiring, and then performs corresponding operations on the target row, at this time, the target transaction is suspended.
In addition, if the target transaction has no line lock conflict with other transactions, it indicates that the target transaction can acquire the mutual exclusive lock of the target line, and performs corresponding operation on the target line.
(12) Deadlock detection is triggered if a first transaction blocking the target transaction is in a suspended state and there is a second transaction blocked by the target transaction.
In this embodiment, deadlock detection is triggered only when a first transaction that satisfies the simultaneous blocking of the target transaction is in a suspended state and there is a second transaction that is blocked by the target transaction. And if there is no second transaction blocked by the target transaction, or the first transaction blocking the target transaction is not in a suspended state, deadlock detection is not triggered.
Here, the above steps 11 to 12 are a specific form of the loop waiting condition among the four requirements for occurrence of deadlock, and thus are also one of the requirements for occurrence of deadlock. That is, when a deadlock occurs, it must occur that the target transaction is in a suspended state, and the first transaction blocking the target transaction is in a suspended state, and there is a second transaction blocked by the target transaction. The inventor finds out through comparison that a great part of conditions which are impossible to generate deadlock can be eliminated through the necessary condition for generating deadlock, and the deadlock detection amount is effectively reduced. And each detection item in the necessary condition of deadlock occurrence is easy to detect, so that even if a step of judging whether the necessary condition is met is added before deadlock detection, the system resources of a database such as a CPU (Central processing Unit) and the like are not excessively occupied. Therefore, the deadlock detection amount of the database lock system is reduced, the deadlock detection efficiency is improved, meanwhile, the CPU resource of the database system is saved, and the concurrent processing capacity of the lock system is improved.
It is understood that in other possible embodiments, the amount of deadlock detection may also be reduced based on other requirements for deadlock occurrence, and is not limited herein.
In at least one possible implementation, after the deadlock detection is triggered, if the result of the deadlock detection is that a deadlock exists, the target transaction is cancelled, so as to avoid that the target transaction cannot be processed in time due to the deadlock.
Compared with the existing deadlock detection mode, the deadlock detection method provided by the embodiment eliminates a part of conditions that deadlock is not possible to occur through the necessary conditions for deadlock occurrence, thereby reducing the times of deadlock detection. For example, according to the prior art, once the background thread finds a pending transaction, deadlock detection is performed, for example, when the transaction T1 acquires a lock already held by the transaction T2, and a lock conflict occurs, the thread will suspend T1, thereby triggering deadlock detection. However, for such a situation, deadlock is not actually generated, and the situation belongs to invalid deadlock detection, and the number of the situation is higher than that of the actual deadlock detection, thereby wasting database system CPU resources and reducing concurrent processing capacity of the lock system. The deadlock detection method can avoid the situation, when the target transaction is suspended, deadlock detection cannot be triggered immediately, and deadlock detection is triggered only when the preset necessary condition for deadlock occurrence is met.
On the basis of the deadlock detection method for database transactions shown in fig. 1, the present embodiment further provides another deadlock detection method, which mainly describes, by an optional embodiment, an implementation process of determining whether a deadlock detection trigger condition is satisfied, that is, a specific implementation process of detecting whether a second transaction blocked by a target transaction exists and detecting whether a first transaction blocking the target transaction is in a suspended state.
Fig. 2 is a schematic flow chart of an alternative deadlock detection method for a database transaction, and as can be seen from fig. 2, the method includes the following steps:
step S202: judging whether the target transaction is in a suspended state; if yes, go to step S204; if not, executing step S212; wherein the target transaction is in a suspended state when the target transaction is blocked.
Here, the target transaction may be suspended when there is a lock conflict with other transactions in the database, which also indicates that there are other transactions blocking the target transaction. In one possible implementation, whether the target transaction is in the suspended state can be determined by the state information of the target transaction. If the target transaction is in the suspended state, further judging whether a first transaction blocking the target transaction is in the suspended state; if the target transaction is not in a suspended state, deadlock detection is not performed.
Step S204: determining whether a first transaction blocking the target transaction is in a pending state; if yes, go to step S206; if not, step S212 is performed.
In one possible implementation, the state information of the first transaction blocking the target transaction may be read, and whether the first transaction is in a suspended state may be determined according to the state information. If the first transaction is also in a suspended state, acquiring a count value of a preset count parameter, wherein the count parameter is used for counting a second transaction blocked by a target transaction; if the first transaction is not in a suspended state, deadlock detection is not performed.
Step S206: and acquiring a count value of a preset count parameter, wherein the count parameter is used for counting the second transaction blocked by the target transaction.
This count value must not be zero if there is a second transaction blocked by the target transaction.
Step S208: judging whether the count value is zero or not; if not, executing step S210; if so, go to step S212.
If the count value is zero, it indicates that there is no second transaction currently blocked by the target transaction, and it is considered that deadlock is not formed, and at this time, deadlock detection is not performed.
If the count value is not zero, it is determined that a second transaction blocked by the target transaction currently exists, and at this time deadlock detection is triggered. Deadlock detection is triggered because the target transaction is suspended, the first transaction blocking the target transaction is also suspended, and there is a second transaction blocked by the target transaction, at which point a deadlock has been formed.
Step S210: determining that there is a second transaction blocked by the target transaction, triggering deadlock detection.
Step S212: deadlock detection is not performed.
Thus, through the above steps S202 to S212, it can be determined whether the deadlock detection triggering condition is satisfied, so as to trigger deadlock detection.
In practical operation, the deadlock detection mode may be implemented by modeling, where a pending transaction is set to from, a waiting transaction is set to, and a sufficient condition for deadlock to occur is set as follows: transaction to is in a suspended state and transaction from blocks other transactions. When the target transaction is processed through the established model, the transaction suspension logic is as follows:
1) a transaction level mutual exclusion lock holding a target transaction;
2) judging whether the target transaction conflicts with other transactions in a row lock manner;
3) if conflict occurs, suspending the target transaction and setting a suspended state;
4) recording the transaction to which the target transaction is blocked, namely recording the logical relationship from \ to;
5) atomically incrementing a block count for the to transaction;
6) if the blocking count of the from transaction is greater than 0 and the to transaction is in a suspended state, performing deadlock detection, otherwise, directly returning;
7) and releasing the transaction-level mutual exclusion lock of the target transaction.
And when the target transaction is processed through the established model, the transaction submission logic is as follows:
1) holding a target transaction mutual exclusion lock;
2) releasing the row lock of the target transaction;
3) acquiring a transaction blocked to a target transaction line lock;
4) holding a mutual exclusion lock of the corresponding transaction blocked by the target transaction;
5) awakening the corresponding transaction;
6) releasing the mutual exclusion lock of the corresponding transaction;
7) releasing a target transaction mutual exclusion lock;
8) resetting the occlusion count;
9) transaction resources are released.
Thus, by the above-described manner of modeling deadlock detection, a large number of invalid deadlock detections are reduced with very low overhead. When the deadlock detection mode is applied to scenes with high conflicts such as second killing and the like, the concurrent processing capacity of the database system can be greatly improved, and the response time consumption of deadlock detection is shortened.
Corresponding to the deadlock detection method for the database transaction shown in fig. 1, an embodiment of the present invention further provides a deadlock detection apparatus for a database transaction, referring to fig. 3, which is a schematic structural diagram of the deadlock detection apparatus for a database transaction, as can be seen from fig. 3, the apparatus includes a requirement determining module 31 and a deadlock detection triggering module 32 connected to each other, where functions of the respective modules are as follows:
a necessary condition determining module 31, configured to determine whether a target transaction meets a preset necessary condition for deadlock occurrence when the target transaction is in a suspended state; wherein the target transaction is in a suspended state when the target transaction is blocked;
a deadlock detection triggering module 32, configured to trigger deadlock detection if the target transaction satisfies the necessary condition for deadlock occurrence.
In one possible implementation, the requirement determining module 31 is further configured to: detecting whether a first transaction blocking the target transaction is in a suspended state and whether a second transaction blocked by the target transaction exists; if a first transaction blocking the target transaction is in a pending state and there is a second transaction blocked by the target transaction, determining that the target transaction satisfies the necessary conditions for deadlock to occur.
In another possible embodiment, the requirement determining module 31 is further configured to: acquiring a counting value of a preset counting parameter, wherein the counting parameter is used for counting a second transaction blocked by the target transaction; and judging whether the count value is zero, and if not, determining that a second transaction blocked by the target transaction exists.
In another possible embodiment, the preset counting parameter is counted in atomic increments.
In another possible implementation, the apparatus further includes a zero module, configured to: if the count value is not zero, clearing the count value under the condition that the target transaction is detected to complete the submission.
In another possible embodiment, the requirement determining module 31 is further configured to: reading state information of a first transaction blocking the target transaction; and judging whether the first transaction is in a suspended state or not according to the state information.
In another possible implementation, the apparatus further includes a transaction retraction module, configured to: and if the deadlock detection result is that the deadlock exists, revoking the target transaction.
The implementation principle and the technical effect of the deadlock detection device for the database transaction provided by the embodiment of the invention are the same as those of the embodiment of the deadlock detection method for the database transaction, and for brief description, corresponding contents in the embodiment of the deadlock detection method for the database transaction can be referred to when the embodiment of the deadlock detection device for the database transaction is not mentioned.
An embodiment of the present invention further provides an electronic device, as shown in fig. 4, which is a schematic structural diagram of the electronic device, where the electronic device includes a processor 41 and a memory 42, the memory 42 stores machine executable instructions that can be executed by the processor 41, and the processor 41 executes the machine executable instructions to implement the deadlock detection method for the database transaction.
In the embodiment shown in fig. 4, the electronic device further comprises a bus 43 and a communication interface 44, wherein the processor 41, the communication interface 44 and the memory 42 are connected by the bus.
The Memory 42 may include a high-speed Random Access Memory (RAM) and may also include a non-volatile Memory (non-volatile Memory), such as at least one disk Memory. The communication connection between the network element of the system and at least one other network element is realized through at least one communication interface 44 (which may be wired or wireless), and the internet, a wide area network, a local network, a metropolitan area network, and the like can be used. The bus may be an ISA bus, PCI bus, EISA bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one double-headed arrow is shown in FIG. 4, but that does not indicate only one bus or one type of bus.
The processor 41 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware or instructions in the form of software in the processor 41. The Processor 41 may be a general-purpose Processor, and includes a Central Processing Unit (CPU), a Network Processor (NP), and the like; the device can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components. The various methods, steps and logic blocks disclosed in the embodiments of the present invention may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present invention may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in a memory, and the processor 41 reads information in the memory 42, and completes the steps of the deadlock detection method for database transactions of the foregoing embodiment in combination with hardware thereof.
An embodiment of the present invention further provides a machine-readable storage medium, where a machine-executable instruction is stored in the machine-readable storage medium, and when the machine-executable instruction is called and executed by a processor, the machine-executable instruction causes the processor to implement the deadlock detection method for a database transaction, where specific implementation may refer to the foregoing method embodiment, and details are not described herein again.
The deadlock detection method for a database transaction, the deadlock detection apparatus for a database transaction, and the computer program product for an electronic device provided in the embodiments of the present invention include a computer-readable storage medium storing a program code, where instructions included in the program code may be used to execute the deadlock detection method for a database transaction described in the foregoing method embodiments, and specific implementation may refer to the method embodiments, and details are not described herein.
The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a non-volatile computer-readable storage medium executable by a processor. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.
In addition, in the description of the embodiments of the present invention, unless otherwise explicitly specified or limited, the terms "mounted," "connected," and "connected" are to be construed broadly, e.g., as meaning either a fixed connection, a removable connection, or an integral connection; can be mechanically or electrically connected; they may be connected directly or indirectly through intervening media, or they may be interconnected between two elements. The specific meanings of the above terms in the present invention can be understood in specific cases to those skilled in the art.
In the description of the present invention, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc., indicate orientations or positional relationships based on the orientations or positional relationships shown in the drawings, and are only for convenience of description and simplicity of description, but do not indicate or imply that the device or element being referred to must have a particular orientation, be constructed and operated in a particular orientation, and thus, should not be construed as limiting the present invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance.
Finally, it should be noted that: the above-mentioned embodiments are only specific embodiments of the present invention, which are used for illustrating the technical solutions of the present invention and not for limiting the same, and the protection scope of the present invention is not limited thereto, although the present invention is described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: any person skilled in the art can modify or easily conceive the technical solutions described in the foregoing embodiments or equivalent substitutes for some technical features within the technical scope of the present disclosure; such modifications, changes or substitutions do not depart from the spirit and scope of the embodiments of the present invention, and they should be construed as being included therein. Therefore, the protection scope of the present invention shall be subject to the protection scope of the appended claims.
Claims (9)
1. A deadlock detection method for a database transaction, comprising:
if the target transaction is in a suspended state, detecting whether a first transaction blocking the target transaction is in the suspended state and whether a second transaction blocked by the target transaction exists; determining that the target transaction satisfies the necessary condition for deadlock to occur if a first transaction blocking the target transaction is in a suspended state and there is a second transaction blocked by the target transaction; wherein the target transaction is in a suspended state when the target transaction is blocked;
and if the target transaction meets the necessary condition for deadlock occurrence, triggering deadlock detection.
2. The deadlock detection method for a database transaction according to claim 1, wherein the step of detecting the presence of a second transaction blocked by the target transaction comprises:
acquiring a counting value of a preset counting parameter, wherein the counting parameter is used for counting a second transaction blocked by the target transaction;
and judging whether the count value is zero, and if not, determining that a second transaction blocked by the target transaction exists.
3. The deadlock detection method for a database transaction according to claim 2, characterized in that the preset counting parameter is counted in an atomic increment manner.
4. The deadlock detection method for a database transaction according to claim 2, characterized in that it further comprises:
and if the count value is not zero, clearing the count value under the condition that the target transaction is detected to be completely submitted.
5. The deadlock detection method for a database transaction according to claim 1, wherein the step of detecting whether a first transaction blocking the target transaction is in a suspended state comprises:
reading state information of a first transaction blocking the target transaction;
and judging whether the first transaction is in a suspended state or not according to the state information.
6. The deadlock detection method of a database transaction according to claim 1, characterized in that after the step of triggering deadlock detection if a first transaction blocking the target transaction is in a suspended state and there is a second transaction blocked by the target transaction, the method further comprises:
and if the deadlock detection result is that the deadlock exists, revoking the target transaction.
7. A deadlock detection apparatus for a database transaction, comprising:
a necessary condition judgment module, configured to detect, when a target transaction is in a suspended state, whether a first transaction blocking the target transaction is in the suspended state, and whether a second transaction blocked by the target transaction exists; determining that the target transaction satisfies the necessary condition for deadlock to occur if a first transaction blocking the target transaction is in a suspended state and there is a second transaction blocked by the target transaction; wherein the target transaction is in a suspended state when the target transaction is blocked;
and the deadlock detection triggering module is used for triggering deadlock detection under the condition that the target transaction meets the necessary condition for generating deadlock.
8. An electronic device comprising a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the deadlock detection method for a database transaction of any of claims 1 to 6.
9. A computer-readable storage medium having stored thereon computer-executable instructions which, when invoked and executed by a processor, cause the processor to implement the deadlock detection method for a database transaction of any of claims 1 to 6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110028189.5A CN112363846B (en) | 2021-01-11 | 2021-01-11 | Deadlock detection method and device for database transaction and electronic equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110028189.5A CN112363846B (en) | 2021-01-11 | 2021-01-11 | Deadlock detection method and device for database transaction and electronic equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112363846A CN112363846A (en) | 2021-02-12 |
| CN112363846B true CN112363846B (en) | 2021-04-13 |
Family
ID=74534688
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110028189.5A Active CN112363846B (en) | 2021-01-11 | 2021-01-11 | Deadlock detection method and device for database transaction and electronic equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112363846B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113076282B (en) * | 2021-04-21 | 2023-06-02 | 中国人民解放军国防科技大学 | Deadlock processing method for processor network-on-chip |
| CN115344360A (en) * | 2021-05-13 | 2022-11-15 | 华为技术有限公司 | Deadlock detection method and device and related equipment |
| CN117076147B (en) * | 2023-10-13 | 2024-04-16 | 支付宝(杭州)信息技术有限公司 | Deadlock detection method, device, equipment and storage medium |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005122560A (en) * | 2003-10-17 | 2005-05-12 | Fujitsu Ltd | Program for detecting deadlock beforehand |
| CN107479980A (en) * | 2016-06-08 | 2017-12-15 | 阿里巴巴集团控股有限公司 | A kind of method and apparatus for detecting deadlock in application |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101576830B (en) * | 2009-06-04 | 2011-11-30 | 中兴通讯股份有限公司 | Deadlock detection method and device of database transaction lock mechanism |
| US9495199B2 (en) * | 2013-08-26 | 2016-11-15 | International Business Machines Corporation | Management of bottlenecks in database systems |
| CN103455368B (en) * | 2013-08-27 | 2016-12-28 | 华为技术有限公司 | A kind of deadlock detection method, node and system |
| CN105426234B (en) * | 2015-10-30 | 2019-02-19 | 小米科技有限责任公司 | Database deadlocks detection method and device |
| CN112181669A (en) * | 2019-07-04 | 2021-01-05 | 中兴通讯股份有限公司 | Deadlock detection control method and device, communication equipment and computer storage medium |
-
2021
- 2021-01-11 CN CN202110028189.5A patent/CN112363846B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005122560A (en) * | 2003-10-17 | 2005-05-12 | Fujitsu Ltd | Program for detecting deadlock beforehand |
| CN107479980A (en) * | 2016-06-08 | 2017-12-15 | 阿里巴巴集团控股有限公司 | A kind of method and apparatus for detecting deadlock in application |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112363846A (en) | 2021-02-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112363846B (en) | Deadlock detection method and device for database transaction and electronic equipment | |
| EP2972885B1 (en) | Memory object reference count management with improved scalability | |
| US7383369B2 (en) | Managing a resource lock | |
| JP6333848B2 (en) | System and method for implementing a statistical counter with scalable competitive adaptability | |
| JP2500101B2 (en) | How to update the value of a shared variable | |
| KR101834262B1 (en) | Enabling maximum concurrency in a hybrid transactional memory system | |
| Alistarh et al. | Threadscan: Automatic and scalable memory reclamation | |
| JPH07191944A (en) | System and method for prevention of deadlock in instruction to many resources by multiporcessor | |
| US10776120B2 (en) | Apparatus and method to generate trace data in response to transactional execution | |
| JP6341931B2 (en) | System and method for implementing a shared probabilistic counter that stores update probability values | |
| JP6310943B2 (en) | System and method for implementing a NUMA aware statistics counter | |
| Brown | Techniques for constructing efficient lock-free data structures | |
| Böttcher et al. | Scalable and robust latches for database systems | |
| CN105824709B (en) | A kind of critical zone access method and device | |
| CN112306699A (en) | Method and device for accessing critical resource, computer equipment and readable storage medium | |
| US20090222494A1 (en) | Optimistic object relocation | |
| US10346196B2 (en) | Techniques for enhancing progress for hardware transactional memory | |
| US9785548B2 (en) | Hardware extensions for memory reclamation for concurrent data structures | |
| Gidenstam et al. | Cache-aware lock-free queues for multiple producers/consumers and weak memory consistency | |
| JPH01297760A (en) | System for lock control and task control in multiprocessor | |
| CN118151887A (en) | Divider data processing method, device, terminal equipment and storage medium | |
| CN112612582B (en) | Semaphore function implementation method and device | |
| CN112148930B (en) | Method, system and medium for graph database system transaction processing based on RTM | |
| Leis et al. | Scalable and Robust Latches for Database Systems | |
| Hemmatpour et al. | Cost Evaluation of Synchronization Algorithms for Multicore Architectures |
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 |