Transaction deadlock testing method and device

Abstract

The present invention provides a transaction deadlock test method and device, belonging to the field of information security technology. The transaction deadlock test method comprises: executing a first transaction according to pre-acquired first business data, and stopping the execution of the first transaction when the first transaction holds preset resources; executing a second transaction according to pre-acquired second business data, and continuing to execute the first transaction when the second transaction enters a waiting state, obtaining a first transaction execution result and a second transaction execution result; and outputting a transaction deadlock test result according to the first transaction execution result and the second transaction execution result. The present invention can effectively reproduce deadlock in a test environment and ensure the accuracy of deadlock testing.

Description

Technical Field

[0001] The present invention relates to the field of information security technology, and in particular to a transaction deadlock testing method and device. Background Art

[0002] In recent years, with the continuous advancement of banking informatization and the continuous increase in business complexity, the complexity of transaction access tables has also increased. When the order of two transaction access tables is inconsistent, it is easy to cause deadlock. Deadlock is a phenomenon in which multiple processes wait for each other due to competition for system resources. Generally, two or more threads hold resources needed by each other, causing these threads to be in a waiting state and unable to continue execution.

[0003] The necessary conditions for deadlock to occur are as follows:

[0004] 1. Mutual exclusion: A certain resource is only allowed to be accessed by one process at a time. When the resource is held by a process, other processes cannot access it until the process releases the resource.

[0005] 2. Hold and wait: A process holds resources (one or more) and waits for other processes to release the resources they hold.

[0006] 3. Non-preemptive: If someone else has occupied a resource, other processes cannot preempt it before the resource is released.

[0007] 4. Circular waiting: There is a process chain so that each process occupies at least one resource required by the next process.

[0008] When all four conditions above are met, a deadlock will occur. After a deadlock occurs, the deadlocked processes cannot be executed, and the resources they hold cannot be released, resulting in a decrease in CPU throughput, a waste of system resources, and a poor performance of the computer.

[0009] When a deadlock occurs in production, the host can print a deadlock report to understand the deadlocked transaction, the resources held by the deadlocked transaction, and the resources it is waiting for. Testers need to reproduce the deadlock in the test environment, verify whether the modified code solves the current deadlock problem, and verify whether a new deadlock occurs.

[0010] Figure 1 is a schematic diagram of the test architecture in the prior art. Figure 1As shown, the stress test server ① sends a business request to execute the deadlock transaction A and B -> the host gateway ② parses the business request and obtains the parsing result -> the host operating system ③ executes business logic processing and SQL (Structured Query Language) in the DB2 database according to the parsing result -> the DB2 database ④ returns the SQL result -> the host operating system ⑤ returns the business result according to the SQL result -> the stress test server ⑥ receives the business result.

[0011] It can be seen from this that the existing technology covers business scenarios for blind stress testing, and prints a deadlock report to verify whether a deadlock occurs when a failed transaction occurs. If a deadlock occurs and the resources held by the deadlock transaction are consistent with the production scenario, it is considered that the deadlock scenario has been reproduced, otherwise it is considered that the production deadlock phenomenon has not been reproduced. In the stress test, it is possible that the thread does not have a circular wait, so there is a possibility that the existing technology cannot reproduce the production deadlock scenario after multiple rounds of testing. Summary of the invention

[0012] The main purpose of the embodiments of the present invention is to provide a transaction deadlock testing method and device, so as to effectively reproduce the deadlock in the test environment and ensure the accuracy of the deadlock test.

[0013] In order to achieve the above object, an embodiment of the present invention provides a transaction deadlock testing method, comprising:

[0014] Execute a first transaction according to the pre-acquired first business data, and stop executing the first transaction when the first transaction holds the preset resources;

[0015] Execute the second transaction according to the pre-acquired second business data, and continue to execute the first transaction when the second transaction enters the waiting state, to obtain the first transaction execution result and the second transaction execution result;

[0016] The transaction deadlock test result is output according to the first transaction execution result and the second transaction execution result.

[0017] The embodiment of the present invention further provides a transaction deadlock testing device, comprising:

[0018] A first transaction execution module, configured to execute a first transaction according to pre-acquired first business data, and stop executing the first transaction when the first transaction holds preset resources;

[0019] An execution result obtaining module, used to execute the second transaction according to the pre-acquired second business data, and continue to execute the first transaction when the second transaction enters the waiting state, to obtain the first transaction execution result and the second transaction execution result;

[0020] The test result output module is used to output the transaction deadlock test result according to the first transaction execution result and the second transaction execution result.

[0021] An embodiment of the present invention further provides a computer device, including a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, the steps of the transaction deadlock testing method are implemented.

[0022] The embodiment of the present invention further provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps of the transaction deadlock testing method are implemented.

[0023] The transaction deadlock testing method and device of the embodiment of the present invention first executes a first transaction and stops executing when the first transaction holds preset resources, then executes a second transaction and continues to execute the first transaction when the second transaction enters a waiting state to obtain a first transaction execution result and a second transaction execution result, and finally outputs a transaction deadlock testing result according to the first transaction execution result and the second transaction execution result, which can effectively reproduce the deadlock in the test environment and ensure the accuracy of the deadlock test. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0025] Figure 1 is a schematic diagram of a test architecture in the prior art;

[0026] Figure 2 It is a test architecture diagram of a transaction deadlock test method in one embodiment of the present invention;

[0027] Figure 3 is a flow chart of a transaction deadlock testing method in one embodiment of the present invention;

[0028] Figure 4 is a flow chart of a transaction deadlock testing method in another embodiment of the present invention;

[0029] Figure 5 This is a first business schematic diagram of a deadlock report in one embodiment of the present invention;

[0030] Figure 6 This is a second business diagram of a deadlock report in one embodiment of the present invention;

[0031] Figure 7 is a structural block diagram of a transaction deadlock testing device in an embodiment of the present invention;

[0032] Figure 8It is a structural block diagram of a computer device in an embodiment of the present invention. DETAILED DESCRIPTION

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

[0034] Those skilled in the art will appreciate that the embodiments of the present invention may be implemented as a system, device, apparatus, method or computer program product. Therefore, the present disclosure may be specifically implemented in the following forms, namely: complete hardware, complete software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.

[0035] In view of the possibility that multiple rounds of testing in the prior art still cannot reproduce the production deadlock scenario, an embodiment of the present invention provides a transaction deadlock test method, which first analyzes the deadlock report, and then sorts out the resources held and waiting for by the deadlock transaction. Taking the deadlock of two processes as an example, first analyzing the deadlock report can find that process P1 holds the lock of table TA1 and waits for the resources of table TB1; process P2 holds the lock of table TB1 and waits for the resources of table TA1. Then track process P1 through PCOMM, and execute process P2 after P1 holds the lock of table TA1. When process P2 is in the waiting state, release process P1 and track it through PCOMM; then print the deadlock report of the DB2 database, analyze the execution results, effectively reproduce the deadlock phenomenon in the test environment, and ensure the accuracy of the deadlock test. The present invention is described in detail below with reference to the accompanying drawings.

[0036] Figure 2 It is a test architecture diagram of a transaction deadlock test method in one embodiment of the present invention. Figure 2 and Figure 1 The test architecture shown is basically the same, except that PCOMM is used for transaction tracking during the test, and the transaction initiation is changed from stress testing to unit testing. Figure 2As shown, during the test, the functional test client ① starts the PCOMM software, links to the host operating system to initiate transaction tracking -> the functional test client ② sends a business request to execute the tracked A and B deadlock transactions -> the host gateway ③ parses the business request and obtains the parsing result -> the host operating system ④ executes business logic processing and SQL (Structured Query Language) in the DB2 database according to the parsing result -> DB2 database ⑤ returns the SQL result -> the functional test client ⑥ ends the tracking -> the host operating system ⑦ returns the business result according to the SQL result -> the functional test client ⑧ receives the business result. Among them, after the transaction enters the tracking state, the single-step execution and calling program mode can be combined to execute until the deadlock report shows that transaction A holds the lock of table TA1, and then execute transaction B.

[0037] Figure 3 It is a flow chart of a transaction deadlock testing method in one embodiment of the present invention. Figure 4 It is a flow chart of a transaction deadlock testing method in another embodiment of the present invention. Figure 5 This is a first business schematic diagram of a deadlock report in an embodiment of the present invention. Figure 6 2 is a second business diagram of a deadlock report in one embodiment of the present invention. Figure 3-Figure 6 As shown, the transaction deadlock test method includes:

[0038] S101: Execute a first transaction according to pre-acquired first business data, and stop executing the first transaction when the first transaction holds preset resources.

[0039] Before executing S101, the method further includes: analyzing a production deadlock report to obtain first business data, second business data, and preset resources.

[0040] by Figure 5 and Figure 6 For example, it can be seen that the first transaction OV2S deadlocks when accessing the table SSRSPKG, and the second transaction OV2R deadlocks when accessing the table SSRIQF2. The second transaction OV2R holds the lock of PAGE=X'024001A9' in the table SSRIQF2, and is waiting for the resource PAGE=X'024004D3' in the table SSRSPKG; while the first transaction OV2S holds the lock of PAGE=X'024004D3' in the table SSRSPKG, and is waiting for the resource PAGE=X'024001A9' in the table SSRIQF2.

[0041] The first business data includes the table SSRSPKG and the resources in the table SSRSPKG, the second business data includes the table SSRIQF2 and the resources in the table SSRIQF2, and the preset resources are the resources PAGE=X'024004D3' that the second transaction OV2R needs to wait for.

[0042] S102: Execute the second transaction according to the pre-acquired second business data, and continue to execute the first transaction when the second transaction enters a waiting state, to obtain the first transaction execution result and the second transaction execution result.

[0043] In specific implementation, when the second transaction enters the waiting state, it indicates that the resources required by the second transaction are held by the first transaction. At this time, releasing the first transaction can verify whether the production deadlock scenario in the production deadlock report is reproduced.

[0044] In one embodiment, S102 further includes: when the second transaction does not enter the waiting state, outputting a transaction deadlock test failure result.

[0045] The prerequisite for the success of the transaction deadlock test is that the second transaction enters the waiting state: when the first transaction OV2S holds the resource PAGE=X'024004D3' required by the second transaction OV2R, the second transaction OV2R must enter the waiting state. When the second transaction does not enter the waiting state, it indicates that the analysis results of the production deadlock report do not match the actual deadlock data, and the test fails.

[0046] S103: Outputting a transaction deadlock test result according to the first transaction execution result and the second transaction execution result.

[0047] In one embodiment, S103 includes: when the first transaction fails to execute and the second transaction succeeds, or when the first transaction succeeds and the second transaction fails to execute, outputting a transaction deadlock test success result.

[0048] Among them, when the transaction deadlock test successfully reproduces the production deadlock scenario in the production deadlock report, one of the transaction processes will be randomly sacrificed to solve the current deadlock problem, and the transaction made by the sacrificed process will fail. Therefore, when the first transaction fails to execute and the second transaction succeeds, or the first transaction succeeds and the second transaction fails, it indicates that the transaction deadlock test is successful. When both the first transaction and the second transaction are executed successfully, or both the first transaction and the second transaction fail, it indicates that the transaction deadlock test has failed.

[0049] The host operating system can also print a test deadlock report to determine whether a deadlock has occurred. If no deadlock is generated in the test deadlock report, it means that the analysis result of the production deadlock report does not match the actual deadlock data, and it is necessary to re-analyze the production deadlock report and re-prepare the data (prepare the first business data, the second business data and the preset resources). If a deadlock occurs, and the resources that are waiting for each other in the test deadlock report are consistent with those in the production deadlock report, it can be considered that the production problem has been reproduced and the transaction deadlock test is successful.

[0050] Figure 3 The execution subject of the transaction deadlock test method shown can be a host operating system. Figure 3 It can be seen from the process shown that the transaction deadlock test method of the embodiment of the present invention first executes the first transaction and stops executing when the first transaction holds preset resources, then executes the second transaction and continues to execute the first transaction when the second transaction enters a waiting state to obtain the first transaction execution result and the second transaction execution result, and finally outputs the transaction deadlock test result according to the first transaction execution result and the second transaction execution result, which can effectively reproduce the deadlock in the test environment and ensure the accuracy of the deadlock test.

[0051] After the deadlock reappears, the developer needs to modify the program. At this time, the deadlock resource order can be adjusted according to the unified specification to avoid deadlock. For example, the resources to be accessed can be sorted according to the primary table and the secondary table, and the primary table resources can be locked first. When a table needs to access multiple records, you can consider locking the resources after sorting the access records in advance. There are many ways to resolve deadlocks, which are not listed here one by one. After modifying the program, the developer can use the same method to continue to verify whether a deadlock occurs in the same scenario. If no deadlock occurs, it can be considered that the modified program has solved the deadlock situation in production.

[0052] The specific process of the embodiment of the present invention is as follows:

[0053] 1. Analyze the production deadlock report to obtain the first business data, second business data and preset resources.

[0054] 2. Execute the first transaction according to the pre-acquired first business data, and stop executing the first transaction when the first transaction holds the preset resources.

[0055] 3. Execute the second transaction according to the pre-acquired second business data, and continue to execute the first transaction when the second transaction enters the waiting state, and obtain the first transaction execution result and the second transaction execution result. When the second transaction does not enter the waiting state, output the transaction deadlock test failure result.

[0056] 4. When the first transaction fails to execute and the second transaction succeeds, or when the first transaction succeeds and the second transaction fails to execute, the transaction deadlock test success result is output.

[0057] In summary, the transaction deadlock testing method provided by the embodiment of the present invention has the following beneficial effects:

[0058] When a deadlock occurs in production, the tester can effectively reproduce the deadlock in the test environment and verify whether the modified code solves the current deadlock problem. The present invention starts with analyzing the deadlock report, making the test more targeted, effectively reproducing the production deadlock situation, avoiding invalid testing, and ensuring the accuracy of the test. To ensure the final modification effect, after the production deadlock situation test is completed, multiple rounds of performance testing can be carried out for typical transactions to verify whether new deadlocks are generated.

[0059] Based on the same inventive concept, an embodiment of the present invention further provides a transaction deadlock testing device. Since the principle of solving the problem by the device is similar to that of the transaction deadlock testing method, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be repeated.

[0060] Figure 7 : is a structural block diagram of a transaction deadlock testing device in an embodiment of the present invention. Figure 7 As shown, the transaction deadlock test device includes:

[0061] A first transaction execution module, configured to execute a first transaction according to pre-acquired first business data, and stop executing the first transaction when the first transaction holds preset resources;

[0062] An execution result obtaining module, used to execute the second transaction according to the pre-acquired second business data, and continue to execute the first transaction when the second transaction enters the waiting state, to obtain the first transaction execution result and the second transaction execution result;

[0063] The test result output module is used to output the transaction deadlock test result according to the first transaction execution result and the second transaction execution result.

[0064] In one embodiment, it also includes:

[0065] The analysis module is used to analyze the production deadlock report to obtain the first business data, the second business data and the preset resources.

[0066] In one embodiment, the test result output module is specifically used for:

[0067] When the first transaction fails to execute and the second transaction succeeds, or the first transaction succeeds and the second transaction fails to execute, a transaction deadlock test success result is output.

[0068] In one embodiment, the test result output module is further used to:

[0069] When the second transaction does not enter the waiting state, the transaction deadlock test failure result is output.

[0070] In summary, the transaction deadlock testing device of the embodiment of the present invention first executes the first transaction and stops executing when the first transaction holds preset resources, then executes the second transaction and continues to execute the first transaction when the second transaction enters a waiting state to obtain the first transaction execution result and the second transaction execution result, and finally outputs the transaction deadlock test result according to the first transaction execution result and the second transaction execution result, which can effectively reproduce the deadlock in the test environment and ensure the accuracy of the deadlock test.

[0071] The embodiment of the present invention also provides a specific implementation of a computer device capable of implementing all the steps in the transaction deadlock testing method in the above embodiment. Figure 8 is a block diagram of a computer device in an embodiment of the present invention, see Figure 8 , the computer equipment specifically includes the following contents:

[0072] Processor (processor) 801 and memory (memory) 802.

[0073] The processor 801 is used to call the computer program in the memory 802. When the processor executes the computer program, all steps in the transaction deadlock test method in the above embodiment are implemented. For example, when the processor executes the computer program, the following steps are implemented:

[0074] Execute a first transaction according to the pre-acquired first business data, and stop executing the first transaction when the first transaction holds the preset resources;

[0075] Execute the second transaction according to the pre-acquired second business data, and continue to execute the first transaction when the second transaction enters the waiting state, to obtain the first transaction execution result and the second transaction execution result;

[0076] The transaction deadlock test result is output according to the first transaction execution result and the second transaction execution result.

[0077] In summary, the computer device of the embodiment of the present invention first executes the first transaction and stops executing when the first transaction holds preset resources, then executes the second transaction and continues to execute the first transaction when the second transaction enters a waiting state to obtain the first transaction execution result and the second transaction execution result, and finally outputs the transaction deadlock test result according to the first transaction execution result and the second transaction execution result, which can effectively reproduce the deadlock in the test environment and ensure the accuracy of the deadlock test.

[0078] The embodiment of the present invention also provides a computer-readable storage medium capable of implementing all the steps in the transaction deadlock testing method in the above embodiment. The computer-readable storage medium stores a computer program. When the computer program is executed by a processor, all the steps in the transaction deadlock testing method in the above embodiment are implemented. For example, when the processor executes the computer program, the following steps are implemented:

[0079] Execute a first transaction according to the pre-acquired first business data, and stop executing the first transaction when the first transaction holds the preset resources;

[0080] Execute the second transaction according to the pre-acquired second business data, and continue to execute the first transaction when the second transaction enters the waiting state, to obtain the first transaction execution result and the second transaction execution result;

[0081] The transaction deadlock test result is output according to the first transaction execution result and the second transaction execution result.

[0082] In summary, the computer-readable storage medium of an embodiment of the present invention first executes the first transaction and stops executing when the first transaction holds preset resources, then executes the second transaction and continues to execute the first transaction when the second transaction enters a waiting state to obtain the first transaction execution result and the second transaction execution result, and finally outputs the transaction deadlock test result according to the first transaction execution result and the second transaction execution result, which can effectively reproduce the deadlock in the test environment and ensure the accuracy of the deadlock test.

[0083] The specific embodiments described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

[0084] Those skilled in the art may also understand that the various illustrative logical blocks, units, and steps listed in the embodiments of the present invention may be implemented by electronic hardware, computer software, or a combination of the two. In order to clearly demonstrate the interchangeability of hardware and software, the various illustrative components, units, and steps described above have generally described their functions. Whether such functions are implemented by hardware or software depends on the specific application and the design requirements of the entire system. Those skilled in the art may use various methods to implement the described functions for each specific application, but such implementation should not be understood as exceeding the scope of protection of the embodiments of the present invention.

[0085] The various illustrative logic blocks, or units, or devices described in the embodiments of the present invention can be implemented or operated by a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field programmable gate array or other programmable logic device, a discrete gate or transistor logic, a discrete hardware component, or any combination of the above. The general-purpose processor can be a microprocessor, and optionally, the general-purpose processor can also be any conventional processor, controller, microcontroller or state machine. The processor can also be implemented by a combination of computing devices, such as a digital signal processor and a microprocessor, a plurality of microprocessors, one or more microprocessors combined with a digital signal processor core, or any other similar configuration.

[0086] The steps of the method or algorithm described in the embodiments of the present invention can be directly embedded in hardware, a software module executed by a processor, or a combination of the two. The software module can be stored in a RAM memory, a flash memory, a ROM memory, an EPROM memory, an EEPROM memory, a register, a hard disk, a removable disk, a CD-ROM, or other storage media of any form in the art. Exemplarily, the storage medium can be connected to the processor so that the processor can read information from the storage medium and can write information to the storage medium. Optionally, the storage medium can also be integrated into the processor. The processor and the storage medium can be arranged in an ASIC, and the ASIC can be arranged in a user terminal. Optionally, the processor and the storage medium can also be arranged in different components in the user terminal.

[0087] In one or more exemplary designs, the above functions described in the embodiments of the present invention can be implemented in hardware, software, firmware or any combination of the three. If implemented in software, these functions can be stored on a computer-readable medium, or transmitted in the form of one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media and communication media that facilitate the transfer of computer programs from one place to another. The storage medium can be any available medium that can be accessed by any general or special computer. For example, such computer-readable media can include but are not limited to RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage or other magnetic storage devices, or any other medium that can be used to carry or store program codes in the form of instructions or data structures and other forms that can be read by general or special computers, or general or special processors. In addition, any connection can be appropriately defined as a computer-readable medium, for example, if the software is transmitted from a website site, server or other remote resource through a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL) or wirelessly, such as infrared, wireless and microwave, it is also included in the defined computer-readable medium. The disk and disc include compact disk, laser disk, optical disk, DVD, floppy disk and blue-ray disk. Disks usually copy data magnetically, while discs usually copy data optically with lasers. The above combination can also be included in computer readable media.

Claims

1. A transaction deadlock testing method, characterized in that: include: Execute a first transaction according to pre-acquired first business data, and stop executing the first transaction when the first transaction holds preset resources; Execute a second transaction according to the pre-acquired second business data, and continue to execute the first transaction when the second transaction enters a waiting state, to obtain a first transaction execution result and a second transaction execution result; Outputting a transaction deadlock test result according to the first transaction execution result and the second transaction execution result; Wherein, the preset resource is the resource that the second transaction needs to wait for; Outputting a transaction deadlock test result according to the first transaction execution result and the second transaction execution result includes: when the first transaction execution fails and the second transaction execution succeeds, or when the first transaction execution succeeds and the second transaction execution fails, outputting a transaction deadlock test success result; The transaction deadlock test method further includes: when the second transaction does not enter the waiting state, outputting a transaction deadlock test failure result.

2. The transaction deadlock testing method according to claim 1, characterized in that: Also includes: Analyze the production deadlock report to obtain the first business data, the second business data and the preset resources.

3. A transaction deadlock testing device, characterized in that: include: A first transaction execution module, configured to execute a first transaction according to pre-acquired first business data, and stop executing the first transaction when the first transaction holds preset resources; An execution result obtaining module, used to execute a second transaction according to the pre-acquired second business data, and continue to execute the first transaction when the second transaction enters a waiting state, to obtain the first transaction execution result and the second transaction execution result; A test result output module, configured to output a transaction deadlock test result according to the first transaction execution result and the second transaction execution result; Wherein, the preset resource is the resource that the second transaction needs to wait for; The test result output module is specifically used to output a transaction deadlock test success result when the first transaction fails to execute and the second transaction succeeds, or when the first transaction succeeds and the second transaction fails to execute; The test result output module is further configured to output a transaction deadlock test failure result when the second transaction does not enter the waiting state.

4. The transaction deadlock testing device according to claim 3, characterized in that: Also includes: The analysis module is used to analyze the production deadlock report to obtain the first business data, the second business data and the preset resources.

5. A computer device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that: When the processor executes the computer program, the steps of the transaction deadlock testing method according to any one of claims 1 to 2 are implemented.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the transaction deadlock testing method according to any one of claims 1 to 2 are implemented.

Images