Transaction nesting detection method, device, equipment, storage medium and program product

Abstract

The application discloses a transaction nesting detection method and device, equipment, a storage medium and a program product, and relates to the technical field of data processing. The connection establishment time and the connection release time of a database can reflect the start time and the end time of database transactions started by a first application service under the same link. The calling link depth can reflect the upstream and downstream relationship of the first application service. The calling mode can reflect the dependency relationship between the database transactions started by the first application service. Based on the start time, the end time, the upstream and downstream relationship and the dependency relationship, whether the database transactions started by the first application service under the same link have a nesting relationship can be accurately determined. Compared with the static code analysis method in the related art, the application can improve the detection accuracy of database transaction nesting.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to transaction nesting detection methods, apparatus, devices, storage media, and program products. Background Technology

[0002] Currently, static code analysis is commonly used to detect nested database transactions. Specifically, it involves scanning the service layer and Data Access Objects (DAO) layer in the application framework's business code to determine if nested database transactions exist.

[0003] Since static code analysis can only analyze the source code of the application framework and cannot analyze the service calls during dynamic operation, if there are multiple service calls under the same call chain, and multiple services under the single application start database transactions at the same time, there is transaction nesting between the multiple services under the single application. However, static code analysis cannot accurately detect this kind of database transaction nesting. Summary of the Invention

[0004] The main objective of this application is to provide a method, apparatus, device, storage medium, and program product for detecting nested transactions, aiming to solve the technical problem of low accuracy in detecting nested database transactions.

[0005] To achieve the above objectives, this application proposes a transaction nesting detection method, applied to a transaction nesting detection device, the method comprising:

[0006] Obtain the database connection logs and link call logs recorded by each application service. The database connection logs include the link identifier, call link depth, database name, database connection establishment time and connection release time of the application service that initiated the service call request. The link call logs include the call method corresponding to the service call request.

[0007] Based on the connection establishment time, connection release time, and invocation method of the database, it is determined whether there is a nested relationship between the database transactions initiated by the first application service under the same link. The first application service under the same link is an application service that initiates database transactions for databases with the same database name under a link with the same link identifier.

[0008] In one embodiment, the step of determining whether there is a nested relationship between database transactions initiated by the first application service under the same link based on the connection establishment time, connection release time, and invocation method of the database includes:

[0009] Determine whether the call chain depth of the first application service is the same;

[0010] If they are not the same, then based on the connection establishment time and connection release time of the database, it is determined whether the duration segments of the database transactions started by the first application service are inclusive.

[0011] If there is an inclusion relationship, then based on the calling method of the upstream application service of the second application service, it is determined whether there is a nested relationship between the database transactions started by the first application service under the same link, wherein the second application service is the application service with the latest connection establishment time among the first application services.

[0012] In one embodiment, the step of determining whether there is a nested relationship between database transactions initiated by the first application service under the same link based on the invocation method of the upstream application service of the second application service includes:

[0013] Starting from the application service above the second application service, iterate through the upstream application services of the second application service to determine whether the invocation method is asynchronous.

[0014] If the upstream application service does not use asynchronous calls, then it is determined that there is a nested relationship between the database transactions started by the first application service under the same link.

[0015] To achieve the above objectives, this application also proposes a transaction nesting detection method, applied to one of the application services, the method comprising:

[0016] In response to a service call request from a target application service to the local machine, the link identifier, call link depth, and call method corresponding to the service call request of the target application service are obtained from the service call request.

[0017] The system executes business processing logic to obtain the database name, connection establishment time, and connection release time of the database. Based on the link identifier, call link depth, database name, database connection establishment time, and connection release time, it generates a database connection log. The business processing logic includes establishing and releasing database connections, so that the transaction nesting detection device can perform transaction nesting detection based on the database connection log and the link call log. The link call log includes the call link depth.

[0018] In one embodiment, the step of executing business processing logic to obtain the database name, connection establishment time, and connection release time, and generating a database connection log based on the link identifier, call link depth, database name, database connection establishment time, and connection release time, includes:

[0019] Execute business processing logic;

[0020] Specifically, during the process of establishing and releasing a database connection, the database name is obtained, and the connection establishment time and connection release time are captured through a predefined AOP aspect. Based on the link identifier, call link depth, database name, database connection establishment time and connection release time, a database connection log is generated. The AOP aspect focuses on the methods called to establish the database connection and the methods called to release the database connection.

[0021] In one embodiment, during the process of establishing a database connection, the database name is obtained, and when the openSession method of SqlSessionFactory is called, the AOP aspect is triggered, and the first aspect logic is executed: based on the database name, link identifier and the call link depth, a log object is created, the database connection establishment time is stored in the log object, and the log object is injected into the SqlSession instance as an InvocationHandler, wherein the connection establishment time is the time when the openSession method is called;

[0022] During the process of releasing the database connection, if the SqlSession instance calls the close method, the AOP aspect is triggered, and the second aspect logic is executed: the connection release time is stored in the log object to obtain the database connection log, and the connection release time is the time when the close method is called.

[0023] Furthermore, to achieve the above objectives, this application also proposes a transaction nesting detection device, which includes:

[0024] The acquisition module is used to acquire the database connection logs and link call logs recorded by each application service. The database connection logs include the link identifier, call link depth, database name, database connection establishment time and connection release time of the application service that initiated the service call request. The link call logs include the call method corresponding to the service call request.

[0025] The judgment module is used to determine whether there is a nested relationship between database transactions initiated by the first application service under the same link, based on the connection establishment time, connection release time, and invocation method of the database. The first application service under the same link is an application service that initiates database transactions for databases with the same database name under a link with the same link identifier.

[0026] In addition, to achieve the above objectives, this application also proposes a transaction nesting detection device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the transaction nesting detection method as described above.

[0027] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the transaction nesting detection method described above.

[0028] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the transaction nesting detection method described above.

[0029] One or more technical solutions proposed in this application have at least the following technical effects:

[0030] The transaction nesting detection device of this application acquires database connection logs recorded by each application service, including the link identifier, call link depth, database name, database connection establishment time, and connection release time of the application service that initiated the service call request, as well as the link call logs including the call method corresponding to the service call request. That is, the transaction nesting detection device can obtain in real time the link identifier, call link depth, database name, database connection establishment time, and connection release time of the application service that initiated the service call request related to the database transaction, as well as the call method corresponding to the service call request related to the link call. Based on the obtained link identifier and link call depth of the application service that initiated the service call request, the first application service under the same link can be determined. It can be understood that the application service that starts a database transaction for a database with the same database name under the link with the same link identifier is the first application service under the same link.

[0031] Since there are multiple services calling a single application under the same call chain, and multiple services under the single application start database transactions simultaneously, there is transaction nesting between the multiple services under the single application. The transaction nesting detection device of this application needs to determine whether there is a nesting relationship between the database transactions started by the first application service under the same chain. Specifically, it can be determined based on the database connection establishment time, connection release time and the calling method. It can be understood that the database connection establishment time and connection release time can reflect the start time and end time of the database transactions started by the first application service for the same database under the same chain. The call chain depth can reflect the upstream and downstream relationship of the first application service under the same chain. The calling method can reflect the dependency relationship between the database transactions started by the first application service. Based on the start time, end time, upstream and downstream relationship and dependency relationship, it is possible to accurately determine whether there is a nesting relationship between the database transactions started by the first application service under the same chain. Compared with the static code analysis method in related technologies, which can only analyze the source code of the application framework and cannot analyze the service call situation during dynamic operation, the above method of this application can improve the detection accuracy of database transaction nesting. Attached Figure Description

[0032] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0033] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0034] Figure 1 This is a flowchart illustrating an embodiment of the transaction nesting detection method of this application.

[0035] Figure 2 This is a schematic diagram of the first scenario provided in Embodiment 1 of the transaction nesting detection method of this application;

[0036] Figure 3 This is a schematic diagram of the second scenario provided in Embodiment 1 of the transaction nesting detection method of this application;

[0037] Figure 4 This is a schematic diagram of the third scenario provided in Embodiment 1 of the transaction nesting detection method of this application;

[0038] Figure 5 This is a schematic diagram of the fourth scenario provided in Embodiment 1 of the transaction nesting detection method of this application;

[0039] Figure 6This is a flowchart illustrating Embodiment 2 of the transaction nesting detection method of this application;

[0040] Figure 7 This is a schematic diagram of the fifth scenario provided in Embodiment 2 of the transaction nesting detection method of this application;

[0041] Figure 8 This is a schematic diagram of the module structure of the transaction nesting detection device according to an embodiment of this application;

[0042] Figure 9 This is a schematic diagram of the device structure of the hardware operating environment involved in the transaction nesting detection method in the embodiments of this application.

[0043] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0044] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0045] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0046] Based on this, embodiments of this application provide a method for detecting nested transactions, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the transaction nesting detection method of this application.

[0047] In this embodiment, the transaction nesting detection method includes steps S10 to S20:

[0048] Step S10: Obtain the database connection log and link call log recorded by each application service. The database connection log includes the link identifier, call link depth, database name, database connection establishment time and connection release time of the application service that initiated the service call request. The link call log includes the call method corresponding to the service call request.

[0049] It should be noted that the execution subject in this embodiment is a transaction nesting detection device. Specifically, it can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device that can realize the above functions.

[0050] Because static code analysis in related technologies can only analyze the application framework's source code and cannot analyze service calls during dynamic runtime, if multiple services within a single application make calls under the same call chain, and multiple services within that single application simultaneously start database transactions, then there is transaction nesting between these services. Figure 2 As shown, application A service A1 and application A service A2 are two services under a single application. The database transaction started by application A service A1 can only end after the downstream request is completed. The database transaction started by the downstream application B service B1 can also only end after the downstream request is completed. The downstream application service of application B service B1 is application A service A2. Therefore, there is a nesting between the database transactions started by application A service A1 and application A service A2. This causes the database connection occupied by application A service A1 to not be released, eventually resulting in a deadlock. However, static code analysis cannot accurately detect this nesting of database transactions.

[0051] To address the aforementioned issues, this embodiment aims to accurately detect the nested nature of database transactions using a transaction nesting detection device.

[0052] First, obtain the database connection logs and call logs recorded by each application service. Specifically, this can be done by using Apache Flink (an open-source framework for stream and batch processing) to obtain database connection logs in real time from Kafka Topics (message storage topics or categories). Alternatively, the corresponding call logs can be obtained by accessing the log management module of each application service, based on the link identifier and call link depth.

[0053] The database connection log includes the link identifier, call link depth, database name, database connection establishment time, and connection release time of the application service that initiated the service call request. Specifically, the database connection log can be recorded in real time by each application service during the execution of business processing logic after responding to the service call request. The link call log includes the call method corresponding to the service call request, and the link call log can be determined and recorded by each application service when initiating the response to the service call request.

[0054] It should be noted that, referring to Figure 3The link identifier can be TraceId, and the call link depth can be determined based on SpanId. The link identifier is generated when the service call request is initiated, and the link identifier is consistent within the same call link. SpanId is used to identify each hop of the call request under the same link. The database name can be database D, database E, etc. The call method corresponding to the service call request includes synchronous call and asynchronous call. The asynchronous call method allows the application service to release the database connection immediately after completing the service call request, without waiting for the return result of the downstream application service, thus avoiding deadlock. The connection release time is the connection establishment time plus the total connection time.

[0055] Step S20: Based on the connection establishment time, connection release time, and invocation method of the database, determine whether there is a nested relationship between the database transactions initiated by the first application service under the same link. The first application service under the same link is an application service that initiates database transactions for databases with the same database name under a link with the same link identifier.

[0056] It should be noted that the database connection establishment time and connection release time can reflect the start and end times of database transactions initiated by the first application service for the same database under the same link. The call link depth can reflect the upstream and downstream relationships of the first application service under the same link. The call method can reflect the dependency relationships between the database transactions initiated by the first application service. Based on the start time, end time, upstream and downstream relationships and dependency relationships, it is possible to accurately determine whether there is a nested relationship between the database transactions initiated by the first application service under the same link.

[0057] Specifically, the first application service under the same link can be selected based on the link identifier and database name summarized from the database connection logs.

[0058] Furthermore, the method for determining whether there is a nested relationship between database transactions initiated by the first application service under the same link based on the connection establishment time, connection release time, and invocation method of the database can be:

[0059] Determine whether the call chain depth of the first application service is the same; if not, determine whether the duration of the database transactions initiated by the first application service is contained within each other based on the connection establishment time and connection release time of the database; if it is contained within each other, determine whether there is a nested relationship between the database transactions initiated by the first application service under the same chain based on the calling method of the upstream application service of the second application service, wherein the second application service is the application service with the latest connection establishment time among the first application services.

[0060] Even if the first application service under the same link starts a database transaction for the same database, it will not cause transaction nesting. Therefore, this embodiment only performs transaction nesting detection on the first application services with different call link depths. The way to determine whether the call link depths of the first application services are the same can be: based on SpanId, determine whether the call link depths are the same. If the size of SpanId is the same, then the call link depths are the same. If the size of SpanId is the same, then there is an upstream and downstream relationship between the first application services. For example, if the SpanIds corresponding to the first application services are 10, 14, and 15 respectively, then the upstream and downstream relationships between the application services corresponding to 10, 14, and 15 are: upstream, midstream, and downstream.

[0061] Furthermore, to facilitate determining whether the duration segments of the database transactions initiated by the first application service are inclusive based on the database connection establishment and release times; when a new database connection log is added to the session window, the database connection logs can be grouped using the session window based on the link identifier, and each group of database connection logs can be sorted in ascending order of time based on the database connection establishment and release times, referring to... Figure 4 .

[0062] Specifically, the connection release time can be used as the session window watermark. When no new connection logs are generated within a preset time period (e.g., within 15 minutes or 20 minutes), it is determined that the session window has ended. It is then determined whether there are database connection logs with inconsistent depths within the session window. If not, new database connection logs are continuously acquired. If there are database connection logs with inconsistent depths, it is then determined whether the duration segments of the database transactions initiated by the first application service are inclusive.

[0063] For example, if the first application service starts database transactions TR1 and TR2 for the same database, and the start time of database transaction TR1 is less than or equal to the start time of database transaction TR2, and the end time of database transaction TR1 is greater than or equal to the end time of database transaction TR2, then it is determined that database transaction TR2 is nested in database transaction TR1, that is, there is an inclusion relationship between TR1 and TR2.

[0064] Furthermore, because asynchronous calls allow application services to immediately release database connections after completing service call requests without waiting for returns from downstream application services, deadlocks are avoided. Therefore, if there is an inclusion relationship between the durations of database transactions initiated by the first application service, it is necessary to consider the relationships between the application services (e.g., application services A1 and A2 corresponding to link 100 are both first application services, and the application services between the first application services include application services C1 and B1 corresponding to link 100, refer to...). Figure 5 The method of calling ) determines whether there is a nested relationship between database transactions started by the first application service under the same link.

[0065] Specifically, it can be determined whether there is a nested relationship between database transactions initiated by the first application service under the same link based on the calling method of the upstream application service of the application service with the latest connection establishment time in the first application service (the second application service, for example, application service A2 corresponding to link 100); or it can be determined whether there is a nested relationship between database transactions initiated by the first application service under the same link based on the calling method of the downstream application service of the downstream application service with the earliest connection establishment time in the first application service (for example, application service A1 corresponding to link 100).

[0066] Specifically, the implementation method for determining whether there is a nested relationship between database transactions initiated by the first application service under the same link based on the invocation method of the upstream application service of the second application service can be as follows:

[0067] Starting from the application service above the second application service, iterate through the upstream application services of the second application service to see if the calling method is asynchronous; if the calling method of the upstream application service is not asynchronous, it is determined that there is a nested relationship between the database transactions started by the first application service under the same link.

[0068] Understandably, one can start from the application service above the second application service (e.g., application service B1 corresponding to link 100) and iterate through the upstream application services of the second application service to determine whether the invocation method is asynchronous; refer to Figure 5 If it is not an asynchronous call, then continue to iterate through the upstream application services of the second application service (e.g., application service C1 corresponding to link 100) to see if their call methods are asynchronous; refer to Figure 5 If it is not an asynchronous call, then it is determined that there is a nested relationship between the database transactions started by the first application service under the same link (between the database transactions started by application service A1 and application service A2 corresponding to link 100 respectively).

[0069] Based on the above method, the dependencies between database transactions initiated during dynamic link calls can be analyzed in real time, and the existence of nested relationships between database transactions can be determined based on the duration of each database transaction. Compared with static code analysis tools, which can only analyze the dependencies between services at the code level and then determine whether nested transaction logic will occur, this embodiment can improve the accuracy of database transaction nesting detection.

[0070] Based on this, the embodiments of this application provide a microservice circuit breaker method, referring to... Figure 6 , Figure 6 This is a flowchart illustrating the second embodiment of the microservice circuit breaker handling method of this application.

[0071] In this embodiment, the transaction nesting detection method includes steps S01 to S03:

[0072] Step S01: In response to the service call request from the target application service to the local machine, obtain the link identifier, call link depth, and call method corresponding to the service call request from the service call request.

[0073] It should be noted that the execution subject of this embodiment is one of the multiple application services.

[0074] Because static code scanning depends on the code scanning rules and the compatibility of the code scanning tool with the development framework, it is difficult for static code scanning to identify database transaction operations in business code that uses custom methods to operate the database or uses aspect-oriented programming such as dynamic proxies, leading to misjudgments and omissions in nested transaction scenarios.

[0075] To address the aforementioned issues, this embodiment aims to identify dynamic database transaction operations and improve the accuracy of detecting nested database transactions.

[0076] Specifically, one of the application services responds to a local service call request Servlet from a target application service other than the one application service itself, and obtains the link identifier, call link depth, and call method corresponding to the target application service from the service call request.

[0077] It is understood that the HTTP header of a service call request will carry the link identifier of the target application service, the call link depth, and the call method corresponding to the service call request; see reference Figure 7One of the application services can obtain the link information by parsing the request header of the service call request: the link identifier of the target application service, the call link depth, and the call method corresponding to the service call request; and store the link information in ThreadLocal (thread-local variable).

[0078] Step S02: Execute business processing logic to obtain the database name, connection establishment time, and connection release time of the database, and generate a database connection log based on the link identifier, call link depth, database name, database connection establishment time, and connection release time. The business processing logic includes establishing and releasing database connections, so that the transaction nesting detection device can perform transaction nesting detection based on the database connection log and link call log. The link call log includes the call link depth.

[0079] Furthermore, one of the application services executes business processing logic: obtaining a database connection, the DAO (Data Access Object) layer handles operations interacting with the database, thereby establishing a database connection, accessing the database, releasing the database connection, and ending the service call, as detailed below. Figure 7 That is, the business processing logic includes establishing a database connection and releasing a database connection.

[0080] It is understood that during the execution of the above business processing logic, the database name, connection establishment time, and connection release time of the database can be obtained, and based on the link identifier, call link depth, database name, database connection establishment time, and connection release time, database connection logs can be generated.

[0081] Specifically, the implementation method for executing business processing logic to obtain the database name, connection establishment time, and connection release time, and generating database connection logs based on the link identifier, call link depth, database name, database connection establishment time, and connection release time can be as follows:

[0082] Execute business processing logic; wherein, during the process of establishing and releasing a database connection, the database name is obtained, and the connection establishment time and connection release time of the database are captured through a predefined AOP (Aspect-Oriented Programming) aspect. Based on the link identifier, call link depth, database name, database connection establishment time and connection release time, a database connection log is generated. The AOP aspect focuses on the methods called to establish the database connection and the methods called to release the database connection.

[0083] It should be noted that during the process of establishing and releasing a database connection, the database connection details can be obtained through the DataSource object, thus obtaining the database name; and the database connection establishment time and connection release time can be captured through predefined AOP aspects.

[0084] For example, define an AOP aspect that executes predefined code before and after the method call it is interested in. For instance, after the method required to establish a database connection is called, the database connection establishment time can be obtained; after the method required to release a database connection is called, the database connection release time can be obtained.

[0085] Specifically, during the process of establishing a database connection, the database name is obtained, and when the openSession method of SqlSessionFactory is called, the AOP aspect is triggered, and the first aspect logic is executed: based on the database name, link identifier, and the call link depth, a log object is created, the database connection establishment time is stored in the log object, and the log object is injected into the SqlSession instance as an InvocationHandler, where the connection establishment time is the time when the openSession method is called.

[0086] It should be noted that when one of the application services detects that the openSession method of SqlSessionFactory is called, it triggers the AOP aspect and executes the first aspect logic (predefined code for the case of focusing on the method called to establish the database connection). Specifically, based on the database name, link identifier and the call link depth, a log object is created, the time when the openSession method is called is used as the database connection establishment time, and the database connection establishment time is stored in the log object.

[0087] Furthermore, in order to record all database transaction operations in real time, the log object can be injected into the SqlSession instance as an InvocationHandler. This allows the SqlSession instance to record information to the log object in real time when it is invoked during subsequent business logic execution.

[0088] Therefore, during the process of releasing the database connection, if the SqlSession instance calls the close method, the AOP aspect is triggered, and the second aspect logic is executed: the connection release time is stored in the log object to obtain the database connection log, and the connection release time is the time when the close method is called.

[0089] Specifically, when the SqlSession instance calls the close method, it indicates that the database connection has ended. At this time, the AOP aspect is triggered, and the second aspect logic is executed (predefined code for the case where the method required to release the database connection is called). For example, the time when the close method is called is used as the connection release time, and the connection release time is stored in the log object to obtain the database connection log. The database connection log is then sent to the preset Kafka Topic.

[0090] The transaction nesting detection device can obtain database connection logs from Kafka Topic in real time and perform dynamic database transaction nesting detection.

[0091] In this embodiment, AOP aspects are defined to dynamically intercept database transaction operations and record the database connection establishment and release times. Compared to static code analysis tools, this embodiment does not depend on the code scanning rules and the compatibility of the development framework. It can dynamically record the statements executed by the database and their execution times, thereby achieving dynamic detection of nested relationships in database transactions and improving the accuracy of database transaction nesting detection.

[0092] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the transaction nesting detection method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0093] This application also provides a transaction nesting detection device, please refer to... Figure 8 The transaction nesting detection device includes:

[0094] The acquisition module 10 is used to acquire the database connection logs and link call logs recorded by each application service. The database connection logs include the link identifier, call link depth, database name, database connection establishment time and connection release time of the application service that initiated the service call request. The link call logs include the call method corresponding to the service call request.

[0095] The judgment module 20 is used to determine whether there is a nested relationship between database transactions initiated by the first application service under the same link based on the connection establishment time, connection release time, and invocation method of the database. The first application service under the same link is an application service that initiates database transactions for databases with the same database name under a link with the same link identifier.

[0096] The transaction nesting detection device provided in this application, employing the transaction nesting detection method in the above embodiments, can solve the technical problem of low detection accuracy of database transaction nesting. Compared with the prior art, the beneficial effects of the transaction nesting detection device provided in this application are the same as those of the transaction nesting detection method provided in the above embodiments, and other technical features in the transaction nesting detection device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0097] This application provides a transaction nesting detection device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the transaction nesting detection method in Embodiment 1 above.

[0098] The following is for reference. Figure 9 The diagram illustrates a structural schematic suitable for implementing a transaction nesting detection device according to embodiments of this application. The transaction nesting detection device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, tablets, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 9 The transaction nesting detection device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0099] like Figure 9As shown, the transaction nesting detection device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the transaction nesting detection device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. The communication device 1009 allows the transaction nesting detection device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows transaction nesting detection devices with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented alternatively.

[0100] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0101] The transaction nesting detection device provided in this application, employing the transaction nesting detection method in the above embodiments, can solve the technical problem of low detection accuracy of database transaction nesting. Compared with the prior art, the beneficial effects of the transaction nesting detection device provided in this application are the same as those of the transaction nesting detection method provided in the above embodiments, and other technical features in this transaction nesting detection device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0102] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0103] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0104] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the transaction nesting detection method in the above embodiments.

[0105] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0106] The aforementioned computer-readable storage medium may be included in the transaction nesting detection device; or it may exist independently and not be assembled into the transaction nesting detection device.

[0107] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the transaction nesting detection device, cause the transaction nesting detection device to execute the aforementioned transaction nesting detection method.

[0108] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0109] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0110] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0111] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described transaction nesting detection method, thereby solving the technical problem of low detection accuracy of database transaction nesting. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the transaction nesting detection method provided in the above embodiments, and will not be repeated here.

[0112] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the transaction nesting detection method described above.

[0113] The computer program product provided in this application can solve the technical problem of low accuracy in detecting nested database transactions. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the transaction nesting detection method provided in the above embodiments, and will not be repeated here.

[0114] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for detecting nested transactions, characterized in that, The method, applied to a transaction nesting detection device, includes: Obtain the database connection logs and link call logs recorded by each application service. The database connection logs include the link identifier, call link depth, database name, database connection establishment time and connection release time of the application service that initiated the service call request. The link call logs include the call method corresponding to the service call request. Based on the connection establishment time, connection release time, and invocation method of the database, it is determined whether there is a nested relationship between the database transactions initiated by the first application service under the same link. The first application service under the same link is an application service that initiates database transactions for databases with the same database name under a link with the same link identifier.

2. The method as described in claim 1, characterized in that, The step of determining whether there is a nested relationship between database transactions initiated by the first application service under the same link based on the connection establishment time, connection release time, and invocation method of the database includes: Determine whether the call chain depth of the first application service is the same; If they are not the same, then based on the connection establishment time and connection release time of the database, it is determined whether the duration segments of the database transactions started by the first application service are inclusive. If there is an inclusion relationship, then based on the calling method of the upstream application service of the second application service, it is determined whether there is a nested relationship between the database transactions started by the first application service under the same link, wherein the second application service is the application service with the latest connection establishment time among the first application services.

3. The method as described in claim 2, characterized in that, The step of determining whether there is a nested relationship between database transactions initiated by the first application service under the same link, based on the invocation method of the upstream application service of the second application service, includes: Starting from the application service above the second application service, iterate through the upstream application services of the second application service to determine whether the invocation method is asynchronous. If the upstream application service does not use asynchronous calls, then it is determined that there is a nested relationship between the database transactions started by the first application service under the same link.

4. A method for detecting nested transactions, characterized in that, Applied to one of the application services, the method includes: In response to a service call request from a target application service to the local machine, the link identifier, call link depth, and call method corresponding to the service call request of the target application service are obtained from the service call request. The system executes business processing logic to obtain the database name, connection establishment time, and connection release time of the database. Based on the link identifier, call link depth, database name, database connection establishment time, and connection release time, it generates a database connection log. The business processing logic includes establishing and releasing database connections, so that the transaction nesting detection device can perform transaction nesting detection based on the database connection log and the link call log. The link call log includes the call link depth.

5. The method as described in claim 4, characterized in that, The steps of executing business processing logic to obtain the database name, connection establishment time, and connection release time, and generating database connection logs based on the link identifier, call link depth, database name, database connection establishment time, and connection release time, include: Execute business processing logic; Specifically, during the process of establishing and releasing a database connection, the database name is obtained, and the connection establishment time and connection release time are captured through a predefined AOP aspect. Based on the link identifier, call link depth, database name, database connection establishment time and connection release time, a database connection log is generated. The AOP aspect focuses on the methods called to establish the database connection and the methods called to release the database connection.

6. The method as described in claim 5, characterized in that, During the process of establishing a database connection, the database name is obtained, and when the openSession method of SqlSessionFactory is called, the AOP aspect is triggered, and the first aspect logic is executed: based on the database name, link identifier and the call link depth, a log object is created, the database connection establishment time is stored in the log object, and the log object is injected as an InvocationHandler into the SqlSession instance, where the connection establishment time is the time when the openSession method is called; During the process of releasing the database connection, if the SqlSession instance calls the close method, the AOP aspect is triggered, and the second aspect logic is executed: the connection release time is stored in the log object to obtain the database connection log, and the connection release time is the time when the close method is called.

7. A transaction nesting detection device, characterized in that, The device includes: The acquisition module is used to acquire the database connection logs and link call logs recorded by each application service. The database connection logs include the link identifier, call link depth, database name, database connection establishment time and connection release time of the application service that initiated the service call request. The link call logs include the call method corresponding to the service call request. The judgment module is used to determine whether there is a nested relationship between database transactions initiated by the first application service under the same link, based on the connection establishment time, connection release time, and invocation method of the database. The first application service under the same link is an application service that initiates database transactions for databases with the same database name under a link with the same link identifier.

8. A transaction nesting detection device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the transaction nesting detection method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the transaction nesting detection method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the transaction nesting detection method as described in any one of claims 1 to 6.

Images