Task Execution Method and Device for a Task Execution Platform Based on Dynamic Class Loading

Through the dynamic class loading task execution platform, the barrier connector and idempotent control are used to solve the queue blocking problem caused by inconsistent subtask execution time and retry times, the correct execution of tasks and data consistency are achieved, and the stability and maintainability of the system are improved.

CN120085940BActive Publication Date: 2025-07-18YUSYS TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202510562329.5
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2025-04-30
Publication Date
2025-07-18
Estimated Expiration
2045-04-30

AI Technical Summary

Technical Problem

In the prior art, the inconsistent execution time and number of retry times of multiple subtasks lead to a problem of blocking the message queue.

Method used

The task execution platform based on dynamic class loading is adopted to ensure that the subtasks are executed in a specific order or condition through barrier connectors and idempotent control. The class loader is managed using the Redis connection pool client and parent delegation mechanism to achieve class uniqueness and consistency, and atomic operations are performed in combination with Lua scripts.

Benefits of technology

It avoids queue blocking, ensures correct execution of tasks and data consistency, and improves system maintainability and performance.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120085940B_ABST
    Figure CN120085940B_ABST
Patent Text Reader

Abstract

The present invention provides a task execution method and device for a task execution platform based on dynamic class loading, belonging to the field of computer technology. The method includes: encapsulating operations related to barrier and idempotency control in a static method of a static utility class; when a task in a class loading request needs to be split into multiple subtasks, calling the static method to trigger class loading, retrieving the connector index through the basic platform class loader, and obtaining a barrier connector class loader corresponding to the class loading request; the barrier connector class loader delegates the class to be loaded to the basic platform class loader, and the basic platform class loader delegates to the JVM class loader to load the jar package of the Redis basic connector, creates a barrier connector object according to the jar package, and establishes a connection with Redis through the Redis connection pool client to execute operations related to barrier and idempotency control. It can avoid the queue blocking problem caused by inconsistent execution times and retry counts of multiple subtasks.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular, to a task execution method and device for a task execution platform based on dynamic class loading. Background Art

[0002] As a storage and transfer center for tasks, a message queue enables producers to encapsulate tasks into messages and send them to the message queue, while consumers retrieve messages from the message queue and execute corresponding tasks. Multiple consumers can simultaneously obtain tasks from the message queue to achieve parallel execution of multiple subtasks. Common message queues include RabbitMQ, Kafka, etc. Taking Kafka as an example, when a task arrives, it is decomposed into multiple subtasks and rewritten into Kafka, meaning that both the upstream and downstream of the function are Kafka. Such operations can cause the storage space required by Kafka to expand rapidly. In addition, some subtasks have additional dependency conditions that are not met. However, when retrying, as long as the subtask is successfully executed, the entire task is considered to be successfully executed, and the process proceeds to the next step.

[0003] For example, when initially using a message queue, a third-party interface is generally called. For instance, the number of allowed retry attempts for a credit investigation interface is inconsistent with the number of detailed query attempts. In terms of business rules, the credit investigation is allowed to be called 2 times, while the details can be queried 10 times. If a certain task fails to execute, the entire task is considered to have failed. Also, due to a network timeout when calling a third-party platform or the previous message in the message queue not being processed, waiting continuously can lead to queue blocking problems caused by inconsistent execution times and retry counts of multiple subtasks during task execution. Summary of the Invention

[0004] In view of this, an object of the embodiments of the present invention is to provide a task execution method and device for a task execution platform based on dynamic class loading, so as to solve the queue blocking problem caused by inconsistent execution times and retry counts of multiple subtasks during task execution in the prior art.

[0005] To achieve the above object, in a first aspect, an embodiment of the present invention provides a task execution method for a task execution platform based on dynamic class loading. The task execution platform includes: a JVM class loader, a basic platform class loader with a connector index, a task loader, a Redis basic connector, and a barrier connector. The method includes:

[0006] Create a static utility class containing static methods in the barrier connector, and encapsulate operations related to barriers and idempotency control in the static methods of the static utility class;

[0007] When the tasks of the class loading requests loaded by the task class loader include multiple subtasks, a static method of the static utility class in the barrier connector is called to trigger class loading, and the class loading triggers the parent delegation mechanism to delegate the class loading request to the basic platform class loader;

[0008] The basic platform class loader retrieves the connector index to obtain the barrier connector class loader corresponding to the class loading request;

[0009] The barrier connector class loader parent-delegates the class loading request to the basic platform class loader, and the basic platform class loader continues to parent-delegate the JVM class loader to load the jar package of the Redis basic connector, and loads the relevant classes of the Redis connection pool client according to the jar package, and returns to the barrier connector class loader to create a barrier connector object;

[0010] The barrier connector object establishes a connection with Redis through the Redis connection pool client and interacts with Redis through the connection;

[0011] The barrier connector object calls the static method to perform operations related to barrier and idempotency control through the static method.

[0012] In a second aspect, an embodiment of the present invention provides a task execution device based on a dynamic class loading task execution platform. The task execution platform includes: a JVM class loader, a basic platform class loader with a connector index, a task loader, a Redis basic connector, and a barrier connector; the device includes:

[0013] A creation module that creates a static utility class containing static methods and encapsulates operations related to barrier and idempotency control in the static methods of the static utility class;

[0014] A trigger and delegation module, which is used to call the static method of the static utility class in the barrier connector to trigger class loading when the tasks of the class loading requests loaded by the task class loader include multiple subtasks, and trigger the parent delegation mechanism through the class loading to delegate the class loading request to the basic platform class loader;

[0015] A retrieval module, which is used for the basic platform class loader to retrieve the connector index to obtain the barrier connector class loader corresponding to the class loading request;

[0016] The delegation and loading module is used for the barrier connector class loader to delegate the class loading request to the basic platform class loader. The basic platform class loader continues to delegate to the JVM class loader to load the jar package of the Redis basic connector, and load the relevant classes of the Redis connection pool client according to the jar package, and then return to the barrier connector class loader to create a barrier connector object;

[0017] The Redis connection module is used for the barrier connector object to establish a connection with Redis through the Redis connection pool client and interact with Redis through the connection;

[0018] The barrier and idempotency control module is used for the barrier connector object to call the static method and perform operations related to barrier and idempotency control through the static method.

[0019] Thirdly, an embodiment of the present invention provides an electronic device, including:

[0020] One or more processors;

[0021] A storage device for storing one or more programs, which when executed by the one or more processors enable the one or more processors to implement a task execution method based on a dynamic class loading task execution platform as described in the first aspect.

[0022] Fourthly, an embodiment of the present invention provides a computer-readable medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements a task execution method based on a dynamic class loading task execution platform as described in the first aspect.

[0023] The above technical solutions have the following beneficial effects:

[0024] In the embodiment of the present invention, the barrier connector is used as a coordination center to ensure that multiple subtasks are executed in a specific order or under specific conditions. It can set barrier points, so that the subtasks pause when reaching the barrier points and wait for other related subtasks to complete before continuing to execute together, avoiding the queue blocking problem caused by inconsistent execution times and retry times of multiple subtasks during task execution;

[0025] In the embodiments of the present invention, the basic platform class loader is used as the parent class loader for all connector class loaders. The related classes of the Redis connection pool client are used as the dependent packages of the platform itself and are loaded in the JVM class loader (alias "app") through the parent delegation mechanism. As a type of connector, the Redis basic connector's class loader depends on the basic platform class loader. During the loading process, following the hierarchical relationship of the class loaders and the parent delegation mechanism can ensure the uniqueness and consistency of classes throughout the Java application, avoid conflicts and chaos caused by different class loaders loading the same class, and ensure that the Redis basic connector can correctly use the related classes of the Redis connection pool client to complete the interaction operations with the Redis database;

[0026] In the embodiments of the present invention, to ensure the uniqueness of classes in the connector index and avoid class conflicts, when packaging the jar package, the connector does not include the basic Redis connection pool client; by directly integrating the Redis connection pool client into the task execution platform packaging, the code and configuration of the Redis connection pool client can be independently managed and maintained. At the same time, it is also convenient to optimize and upgrade the functions of the connection pool without affecting the functions of other connectors.

[0027] In the embodiments of the present invention, by setting parameters in Redis, implementing atomic operations using Lua scripts, and combining the encapsulation of utility classes, the idempotency control and barrier management of tasks are achieved, ensuring the correct execution of tasks and data consistency in a distributed environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the following described drawings are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0029] Figure 1 is a flowchart of a task execution method of a task execution platform based on dynamic class loading according to an embodiment of the present invention;

[0030] Figure 2 is a functional block diagram of a task execution platform based on dynamic class loading according to an embodiment of the present invention;

[0031] Figure 3 is a flowchart of the implementation of barrier and idempotency control according to an embodiment of the present invention;

[0032] Figure 4 is a schematic diagram of the principle of a barrier according to an embodiment of the present invention;

[0033] Figure 5 is a functional block diagram of a task execution device of a task execution platform based on dynamic class loading according to an embodiment of the present invention;

[0034] Figure 6 is a functional block diagram of an electronic device according to an embodiment of the present invention. Detailed implementation manners

[0035] Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although some embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. On the contrary, these embodiments are provided to more thoroughly and completely understand the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are only for exemplary purposes and are not used to limit the protection scope of the present disclosure.

[0036] It should be understood that the steps recited in the method embodiments of the present disclosure can be executed in different orders and / or in parallel. In addition, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present disclosure is not limited in this regard.

[0037] The term "including" and its variants used herein are open-ended, that is, "including but not limited to". The term "based on" is "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". The relevant definitions of other terms will be given in the following description.

[0038] It should be noted that the concepts such as "first" and "second" mentioned in the present disclosure are only used to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependent relationships.

[0039] It should be noted that the modifications of "one" and "multiple" mentioned in the present disclosure are illustrative rather than restrictive. Those skilled in the art should understand that unless otherwise clearly specified in the context, it should be understood as "one or more". Embodiment 1

[0040] As Figure 2As shown in the figure, the task execution platform includes: a JVM (Java Virtual Machine) class loader, a basic platform class loader with a connector index, a task class loader, a Redis basic connector loaded in the JVM class loader, and a barrier connector class loader created by a connector loader. Among them, in this task execution platform, a group of connector class loaders is created by the connector loader, a group of task class loaders is created by the task connector, and a group of policy class loaders is created by the policy loader. Each group generates an independent and isolated class loader for each loaded jar (Java Archive) package. Among them, the group of task class loaders is uniformly managed by a common task class loader, and the jar package of the Redis basic connector is integrated in the JVM class loader in the platform. A connector index and a reference index can also be built in the basic platform class loading. The basic platform class loader will find the corresponding connector class loader through the connector loader, and through the reference index, all policy class loaders and task class loaders that use the classes in the connector can be retrieved according to the connector name when reloading the jar package.

[0041] In this embodiment, a subclass loader, that is, a basic platform class loader, is created from the application container class loader ("app") predefined by the JVM virtual machine. In Java, the application class loader (also known as the system class loader) is one of the class loaders predefined by the JVM and is responsible for loading classes under the application class path (classpath). All class loaders in this embodiment follow the parent delegation mechanism and use the basic platform class loader as their parent class loader. When executing a task, the barrier connector will be loaded in sequence according to the path of the task class loader, the common task class loader, the basic platform class loader, the connector index, and the barrier connector class loader. The Redis basic connector is a compilation dependency package of the barrier connector, and the barrier connector creates a Redis connection pool through the classes in the basic connector.

[0042] The barrier connector is a plugin of the platform and is integrated with the platform to provide specific functions for the platform. The barrier connector has its own independent code structure and functional logic and can be developed, tested, and maintained without affecting other parts of the platform. For example, if the platform is a data processing system, the barrier connector can be used to set a barrier during the data processing process to ensure that the data is processed synchronously or asynchronously under specific conditions, thereby meeting different business requirements.

[0043] Redis is mainly used to provide support for atomic operations in distributed systems. Since Redis is commonly used in current distributed systems, when it is used as a connector, the problem of sharing the Redis connection pool with other connectors will definitely be faced. Therefore, in this embodiment, a shared jar package is provided through the Redis basic connector. However, it is not mounted on the tree related to the basic platform class loader in the form of a class loader, but is packaged as an independent jar package into the platform. Its classes are actually located in the parent class loader of the basic platform class loader, that is, the classes therein are loaded by the basic platform class loader through further parent delegation upwards. The barrier connector class loader will load a series of classes. When loading dependent classes, since the jar package of the barrier connector does not include the classes of the Redis basic connector during packaging, this loading action will again go through parent delegation back to the basic platform class loader. Then, if this class does not exist in the connector index, it will continue to be parent-delegated to the parent class loader of the basic platform class loader, that is, the app class loader in the JVM. Therefore, the jar package of the Redis basic connector is directly integrated into the platform, and relevant classes will not be repackaged when the connector is released, which can reduce the volume of the jar package and also avoid the problem that different connectors based on the Redis connection pool use different versions of Redis client classes, resulting in unknown Redis connections.

[0044] As Figure 1 shown, the method includes the following steps:

[0045] Step S11, create a static utility class containing static methods in the barrier connector, and encapsulate the operations related to the barrier and idempotency control in the static methods of the static utility class.

[0046] A barrier is a data structure used to record and control the execution status of business subtasks. It can be imagined as an array or bitmap with a specific length (determined by the number of subtasks barrierCount), and each position corresponds to the execution status of a subtask. By checking the value at the corresponding position of the barrier (0 indicates not executed, 1 indicates executed), it is possible to determine whether a subtask has been executed, thereby avoiding operations such as locking on an already executed subtask again, ensuring the idempotency of the operation. Idempotency means that the impact of an operation, whether it is executed once or multiple times, is the same as the impact of executing it once. When the barrier positions corresponding to all subtasks are set to 1, it indicates that all subtasks of the entire business have been successfully executed, and subsequent business process control or status judgment can be carried out based on this.

[0047] Static utility classes contain static methods that can be called directly through the class name without creating an instance of the class. For example, in Java, the Math class is a static utility class, and Math.sqrt() can be directly used to calculate the square root without first creating an object of the Math class. In this embodiment, complex operations related to barriers and idempotency control, such as locking, unlocking, canceling, etc., are encapsulated in the static methods of a static utility class. The static utility class encapsulates these complex instruction details. Business logic developers do not need to care about how the specific Redis instructions are executed, nor do they need to handle issues such as the establishment and closing of connections and the construction of instruction formats. The utility class will handle these details internally and only provide a simple interface to the business logic. For example, the utility class is responsible for establishing a connection to the Redis server internally, converting the parameters passed by the business logic into the correct Redis instruction format and sending them, then parsing and processing the results returned by the server, and finally returning the processed results to the business logic.

[0048] In this embodiment, by creating a static utility class, the specific implementation details of complex operations related to barriers and idempotency control can be hidden, and only a simple and unified interface is exposed to the outside. Other codes only need to call these static methods to complete the corresponding operations without having to understand the internal specific implementation logic, which improves the maintainability and reusability of the code.

[0049] Step S12, when the task of the class loading request loaded by the task class loader needs to be split into multiple subtasks, call the static method of the static utility class in the barrier connector to trigger class loading, and trigger the parent delegation mechanism through the class loading to delegate the class loading request to the basic platform class loader.

[0050] In this embodiment, when the task of the class loading request loaded by the task class loader needs to be split into multiple subtasks, by calling the try-lock method of the utility class, the utility class triggers class loading, and the class loading triggers the parent delegation.

[0051] Since different connectors depend on different versions of classes, if each connector has its own independent class loader and there is no unified management, it is very easy to have class conflict problems. In this embodiment, by setting the basic platform class loader as the parent class loader, the classes related to the connectors can be uniformly managed to ensure that the classes used between different connectors are consistent and avoid compatibility problems caused by different versions of classes.

[0052] Step S13, the basic platform class loader retrieves the connector index to obtain the barrier connector class loader corresponding to the class loading request.

[0053] In this embodiment, after creating the basic connector, a connector index is constructed inside the basic connector. The connector index records the connectors to which each class belongs, facilitating quick location of the corresponding connector during class loading. This connector index uses the data structure of a Java hash dictionary index forest to retrieve connectors based on class names. The hash dictionary index forest is a data structure composed of multiple hash dictionaries, similar to a collection of multiple hash tables. Each hash table can store data according to different rules or classifications. After the basic connector loads a class loading request, it retrieves the connector index to quickly locate the corresponding barrier connector class loader.

[0054] In step S14, the barrier connector class loader delegates the class loading request to the basic platform class loader. The basic platform class loader continues to delegate to the JVM class loader to load the jar package of the Redis basic connector, loads the Redis connection pool client class based on the jar package, and returns to the barrier connector class loader to create a barrier connector object.

[0055] In this embodiment, the Redis basic connector utilizes Redis to implement distributed primitive functions and achieve basic operations and specific business logics for interacting with Redis. In the platform, many distributed primitive functions based on Redis rely on the Redis basic connector to complete, such as distributed locks, distributed counters, etc. It mainly focuses on how to use various features of Redis to meet business requirements and is a bridge for interacting with Redis at the business logic level. When an application initiates an interaction request with the Redis server, the request is first processed by the barrier connector (such as data filtering, verification, etc.), and then the Redis client sends the processed command to the Redis server through the connection.

[0056] Specifically, after receiving a class loading request, the barrier connector class loader will first follow the parent delegation model and delegate the request to its parent class loader, i.e., the basic platform class loader. This allows the parent class loader to attempt to load the class first, avoiding duplicate loading and ensuring the uniqueness of the class. In Java, the class loader checks whether it has already loaded the class. If not, it continues to delegate upward. After receiving the class loading request, the basic platform class loader also follows the parent delegation model and further delegates the request to its parent class loader, i.e., the JVM class loader (AppClassLoader). This is the normal process of parent delegation in the Java class loading mechanism, ensuring that classes are loaded by the appropriate class loader. The JVM class loader attempts to load the jar package of the Redis basic connector on which the barrier connector class loader depends, searches for the corresponding jar package in its specified class path, and reads the class bytecode file from it. For example, assuming the jar package of the Redis basic connector is in the classpath, AppClassLoader will automatically search this path to find and load the relevant classes. When the barrier connector class loader is successfully loaded into the JVM, the program can create an instance of this class, i.e., the barrier connector object, through reflection or other means.

[0057] Through this hierarchical relationship of class loaders and the parent delegation mechanism, it is possible to ensure the uniqueness and consistency of classes throughout the Java application, avoid conflicts and confusion caused by different class loaders loading the same class, and ensure that the Redis basic connector can correctly use the classes of the Redis connection pool client to complete the interaction operations with the Redis database.

[0058] In this embodiment, to ensure the uniqueness of classes in the connector index and avoid class conflicts, when packing the jar package, the Redis basic connector does not include the basic Redis connection pool client. The Redis connection pool client is directly integrated into the task execution platform for packaging. This can independently manage and maintain the code and configuration of the Redis connection pool client, and at the same time facilitate the optimization and upgrade of the connection pool function without affecting the functions of other connectors.

[0059] Step S15, the barrier connector object establishes a connection with Redis through the Redis connection pool client and interacts with Redis through the connection.

[0060] The Redis connection pool client is used to manage connections to the Redis database. It is implemented independently based on Netty and is directly integrated into the task execution platform package. During the operation of the platform, it needs to interact with the Redis database. The Redis connection pool client provides functions such as connection management and resource allocation to ensure that the platform can access the Redis database efficiently and stably. The related classes of the Redis connection pool client include various classes and interfaces for implementing the connection pool function, such as classes for connection creation, connection destruction, connection acquisition, connection return, etc., as well as classes for configuring connection pool parameters. It is the basis for the platform to implement the interaction function with the Redis database, and the platform relies on these classes to complete the business logic related to Redis.

[0061] In this embodiment, through the connection pool technology, it can avoid the performance overhead caused by frequent creation and destruction of connections, and improve the efficiency and stability of the system's interaction with Redis.

[0062] Step S16, the barrier connector object calls a static method to perform operations related to the barrier and idempotency control through the static method.

[0063] The barrier connector object is responsible for managing parameters related to the barrier and idempotency control, such as the business identification number (barrierKey), the number of subtasks (barrierCount), the subtask number (barrierNo), and the application identification number for calling the barrier (instanceId), etc. The static method of the static utility class performs corresponding operations according to the received parameters. For example, when the barrier connector object calls the unlock static method of the static utility class, it will pass parameters such as the subtask number, the application identification number, and the number of subtasks, so that the static method can accurately perform the unlock operation and determine whether the barrier has been completed. The static method of the static utility class performs corresponding operations according to the received parameters. For example, when the barrier connector object calls the unlock static method of the static utility class, it will pass parameters such as the barrier key, the subtask number, the application identification number, and the number of subtasks, so that the static method can accurately perform the unlock operation and determine whether the barrier has been completed.

[0064] In this embodiment, the barrier connector object encapsulates the specific operations of the barrier and idempotency control, and exposes the functions externally through the provided static methods (such as tryLock for attempting to lock, unlock for unlocking, and cancel for cancellation). These static methods internally call the relevant methods of the barrier connector object to execute the specific operation logic. For example, in the tryLock method, it will call the method of the connector object that interacts with Redis to execute the Lua script for locking and return the locking result; the unlock method will execute the Lua script for unlocking and determine whether the barrier has been completed based on the return value of the script. In this way, the barrier connector object encapsulates the complex barrier and idempotency control operations, provides a simple and easy-to-use interface, and facilitates other code to call and use.

[0065] The static methods of the static utility class encapsulate the specific operation logic and provide functional support for the barrier connector object. The details of the interaction with Redis are implemented inside the static methods, such as executing operations like locking, unlocking, and cancellation through Lua scripts. By calling these static methods, the barrier connector object does not need to understand the underlying implementation details and only needs to focus on the parts related to the business logic, thus achieving code separation and modularization, and improving the maintainability and scalability of the code. The barrier connector object maintains its own state based on the execution results of the static methods of the static utility class. For example, after calling the static method for locking, the barrier connector object will determine whether the locking is successful based on the return result and set its own locking status flag accordingly. In subsequent operations, the barrier connector object can decide whether to continue executing other relevant operations based on its own state. For example, in the case of successful locking, it will execute the specific business logic, or after the unlocking operation, it will decide whether to proceed to the next step based on the barrier state. The barrier connector object and the static methods of the static utility class that encapsulate the barrier and idempotency control operations cooperate with each other to jointly implement the functions of the barrier and idempotency control. Among them, the barrier connector object, as the caller and parameter manager, relies on the static methods of the static utility class to complete the specific complex operations and maintains its own state based on the operation results to support the execution of the business logic.

[0066] In the embodiments of the present invention, the Java class file is loaded in the barrier connector. When the static method of the static utility class is called for the first time, it will trigger the Java class loading mechanism. Since the business code is loaded in a single isolated task class loader, when it executes to the static class method, it will follow the class loading route in the connector class, and the barrier connector class loader will be created by the connector loader (manager). The barrier connector class loader will load this static class. When the method of the static class is executed, it will call the class in the barrier connector again and execute the connector class loading path once more. The barrier connector class loader will load the corresponding Redis connection and the processing logic of the barrier and idempotency. When loading the Redis connection pool, since there is no relevant class in the barrier connector, it will be delegated to the base platform class loader through the parent delegation mechanism, and then the app class loader will be searched upward to load this class. Then the logic will return to the barrier class loader to continue loading and executing the barrier processing code, and finally return the processing result to the class in the task class loader.

[0067] In the embodiments of the present invention, the barrier connector is used as a coordination center to ensure that multiple subtasks are executed in a specific order or under specific conditions. It can set barrier points so that the subtasks pause when they reach the barrier points and wait for other relevant subtasks to complete before continuing to execute together, avoiding the problem of queue blockage caused by inconsistent execution times and retry counts of multiple subtasks during task execution.

[0068] In some embodiments, in step S14, the barrier connector object establishes a connection with Redis through the Redis connection pool client and interacts with Redis through the connection. Specifically, it includes:

[0069] Step S141: Obtain a connection from the Redis connection pool client. Among them, the relevant classes of the Redis connection pool client are used as the dependent packages of the platform and are loaded in the JVM class loader through the parent delegation mechanism to implement the connection management and resource allocation when the platform interacts with the Redis database.

[0070] Specifically, the Redis connection pool client is responsible for managing the connection pool with the Redis server and can create, maintain, and allocate connection resources. When the barrier connector interacts with Redis, it will obtain a connection from the Redis connection pool client instead of establishing a new connection every time, which can improve the reuse rate of connections, reduce the overhead of connection creation and destruction, and improve the system performance and stability. When the barrier connector finishes using the connection, it will return the connection to the connection pool for other components to use again.

[0071] In this embodiment, the relevant classes of the Redis connection pool client are loaded in the JVM class loader through parent delegation, making these classes shared resources as well. Multiple connectors can share the same Redis connection pool client instance, improving resource utilization and avoiding resource waste caused by repeatedly creating connection pools. When it is necessary to upgrade or modify the relevant classes of the Redis connection pool client, only the update needs to be performed at the platform level, rather than separately in each connector, improving the maintainability of the system.

[0072] Step S142: Create an instance of the Redis basic connector in the code logic of the barrier connector object or reference an existing instance of the Redis basic connector.

[0073] Specifically, the barrier connector is mainly responsible for handling business logics related to barriers and idempotency control. And these related business logics need to store data into Redis or read data from Redis. By creating or referencing an instance of the Redis basic connector, the barrier connector can utilize the functions it provides to interact with the Redis server, thereby implementing the functions of idempotency control and barrier synchronization. Idempotency control means that by storing the unique identifier of a request in Redis, it is judged whether the request has been processed, avoiding repeated processing. Barrier synchronization means setting and checking the barrier status in Redis to ensure that multiple tasks continue to execute only after meeting specific conditions.

[0074] Step S143: The barrier connector object calls the methods provided by the Redis basic connector through the instance to interact with the Redis server according to the connection. The methods provided by the Redis basic connector include connection establishment, command execution, and connection management.

[0075] In this embodiment, the basic platform class loader provides a class loading basis for the operation of the barrier connector. The Redis basic connector provides underlying operation support for the interaction between the barrier connector and Redis. The Redis basic connector provides underlying functions such as establishing a connection with the Redis server and executing basic commands. The Redis connection pool client, on the other hand, provides an efficient management mechanism for the connection between the barrier connector and Redis. The barrier connector realizes the operation of data in Redis by calling the methods of the Redis basic connector. They cooperate together to enable the barrier connector to normally realize its functions in the application program, ensuring the reliability and performance of the system.

[0076] In some embodiments, the barrier connector object calls static methods to perform operations related to barriers and idempotency control through the static methods, specifically including:

[0077] When the barrier connector object calls the unlock static method of the static utility class, it passes the relevant parameters set in Redis to the static method of the static utility class. The relevant parameters include the business identification number, sub-task number, number of sub-tasks, and application identification number for calling the barrier. Among them, the business identification number is used to uniquely identify a business operation or business process. Different business operations should have different business identification numbers. The number of sub-tasks is the number of sub-tasks into which the entire business operation is split. The sub-task number is used to identify the number of the currently executing sub-task. The application identification number for calling the barrier is used to uniquely identify the application instance that calls the barrier and distinguish different application instances in the distributed system. The static method of the static utility class performs operations related to barrier and idempotency control based on the relevant parameters and the Lua script of Redis. Among them, the static methods include a try-lock method, an unlock method, and a cancel method.

[0078] Specifically, parameters such as the business identification number (barrierKey), number of sub-tasks (barrierCount), sub-task number (barrierNo), and application identification number for calling the barrier (instanceId) are set in Redis. These parameters are the basic information for implementing barrier and idempotency control and are used to identify and distinguish different tasks, sub-tasks, and application programs. When a lock request arrives, it is processed through a Lua script. First, it checks the position of the flag bit corresponding to the barrier. If the value of the position of the flag bit is 1, it indicates that the sub-task has been executed and directly skips the subsequent execution and returns a failed lock. If it is 0, it performs the locking operation of the idempotent lock, sets the value of the idempotent lock to the application identification number, sets an expiration time for it, and then returns whether the lock is successful.

[0079] The sub-task that successfully locks can execute the business code. When the business code is executed successfully, an unlock operation is performed. The idempotent lock is deleted through a Lua script, and the position of the flag bit corresponding to the barrier is set to 1. Then it checks whether all flag bits of the barrier have reached 1 to determine whether all sub-tasks have been successfully executed. When the business code fails to execute, a cancel operation is performed, and only the idempotent lock is deleted.

[0080] In this embodiment, the locking script first obtains the value of the position of the flag bit corresponding to the barrier and determines whether it has been executed. If it has not been executed, it attempts to lock. If the lock is successfully obtained, it returns 1; otherwise, it returns 0. The unlocking script first deletes the idempotent lock, sets the position of the flag bit corresponding to the barrier to 1, and then checks whether the positions of all flag bits are 1. If so, it returns 1 indicating that the barrier is completed; otherwise, it returns 0. The cancellation script only deletes the idempotent lock and returns a success flag. Through these Lua scripts, atomic operations of the barrier and idempotency control module are achieved, ensuring data consistency and correctness in a distributed environment. At the same time, leveraging the single-threaded feature of Redis, it is ensured that the script will not be interrupted by other commands during execution, avoiding the occurrence of race conditions.

[0081] In a distributed system or a multi-threaded environment, the same operation may be executed multiple times. In this embodiment, by setting an idempotent lock with the application identification number as the lock value, it can be ensured that the same operation of the same application can only be executed once within the valid time of the lock. For example, when processing order payments, it can prevent the same payment request from being processed multiple times due to network fluctuations or other reasons, avoiding problems such as duplicate deductions. When multiple applications or threads access and modify shared resources simultaneously, the idempotent lock can play a role in protecting the resources. Only the application that obtains the lock can operate on the resources, and other applications need to wait. For example, when multiple applications simultaneously update the same record in the database, the idempotent lock can ensure that only one application can successfully update each time, avoiding data inconsistency.

[0082] By setting an expiration time, it can be avoided that the lock is held indefinitely due to certain abnormal situations, thus causing a deadlock. Without an expiration time, once an application obtains the lock and then fails or has a program exception, the lock will never be released, and other applications will not be able to obtain the lock, resulting in the system being unable to operate normally. The expiration time can ensure that after a certain period, even if the application holding the lock does not actively release the lock, the lock will automatically become invalid, and other applications can continue to attempt to obtain the lock and perform corresponding operations. The expiration time can be reasonably set according to business requirements, enabling the system to improve the concurrent processing ability as much as possible while ensuring idempotency and resource protection. When the lock expires, other applications can obtain the lock and execute operations in a timely manner, avoiding long waiting times, thereby improving the overall performance and response speed of the system.

[0083] As Figure 3 shown, in some embodiments, the static method of the static utility class performs operations related to barrier and idempotency control according to relevant parameters and Redis Lua scripts, specifically including:

[0084] S1, the barrier connector obtains a locking request;

[0085] S2. Before executing the business code of each subtask, call the try-lock method. Check, through a Lua script, whether the value at the position corresponding to the flag bit of each subtask in the barrier is 1. If the value at the position of the flag bit is 1, it is regarded as a failed lock. If the value at the position of the flag bit is not 1 (i.e., 0), then execute S3;

[0086] S3. Determine whether an idempotent lock exists. If an idempotent lock exists, it is regarded as a failed lock. If no idempotent lock exists, then set the idempotent lock; and set the value of the idempotent lock to the application identification number, and at the same time set the expiration time of the idempotent lock; if the lock is successfully acquired, then execute S4; if the lock acquisition fails, skip the subsequent processing of the subtask;

[0087] S4. Execute the business code of the subtask;

[0088] S5. Determine whether the business code of the subtask is successfully executed. If it is successfully executed, then call the unlock method to unlock and execute S6; if the execution fails, execute S7;

[0089] S6. Set the value at the position corresponding to the flag bit of the subtask to 1, and check whether the values at the positions corresponding to the flag bits of all subtasks in the barrier are all 1. If the values at the positions of all flag bits are all 1, it indicates that all related subtasks have been completed, execute the subsequent operations and jump out of the loop; if there are unfinished subtasks, continue to wait until the task ends;

[0090] S7. Delete the idempotent lock.

[0091] In addition, if an exception occurs during the execution of the business code of the subtask, perform a cancellation operation through the cancellation method in the static method.

[0092] As Figure 4 shown, in this embodiment, the flag bit corresponding to each subtask in the barrier is stored in the Redis data structure in the form of a bitmap. The number of flag bits is the same as the number of subtasks. Perform a bitwise verification on each flag bit in the barrier. The idempotent lock calls the business identification number of the barrier according to the subtask number. Each row represents a key-value pair in Redis. The "business identification number" and "business identification number: subtask number / subtask count" in front are the key names. In this embodiment, through the storage of the flag bits in the bitmap, on the one hand, double-lock verification can be achieved to avoid the problem of the failure of the coarse-grained distributed lock in the concurrent state in special cases. On the other hand, it can avoid the high memory occupation caused by the retention of a large number of idempotent locks.

[0093] In this embodiment, when each subtask successfully acquires the try-lock, wrap the business code with try-catch. The try block is used to wrap the code that will throw an exception; the catch block is used to catch and handle the exception thrown in the try block;

[0094] Specifically, when the subtask successfully acquires the lock, its core business code will be placed in a try block. During the execution of the business code, exceptions may be thrown for various reasons, such as network failures, data format errors, resource shortages, etc. Using try-catch can capture these exceptions and handle them accordingly, such as logging, rolling back operations, giving user prompts, etc., to prevent the program from crashing due to unhandled exceptions. The try block is used to wrap the code that throws exceptions. The catch block is used to capture and handle the exceptions thrown in the try block. If an exception occurs during the execution of the subtask's business code, the cancellation operation is performed through the cancellation method in the static method, and the cancellation operation is placed in the catch block of the code. This can ensure that even if an exception occurs during the execution of the business code, the exception can be properly handled, and at the same time, the lock can be released correctly. That is, regardless of whether the business code is executed normally to completion, it is necessary to ensure that the lock can be released to avoid deadlocks or resource leaks.

[0095] In this embodiment, the operations are encapsulated by adding a static utility class. The barrier connector object is obtained through the unified environment and passed as a parameter to the static method. Three static methods, namely tryLock, unlock, and cancel, are set. When subtasks are required, asynchronous traversal is performed. When each subtask successfully acquires the lock using tryLock, the business code is wrapped with try - catch. After the business code is executed, the lock is released and the return value is obtained. If the return value is true, the subsequent operations are executed and the loop is exited. The cancellation operation is placed in the catch block of the code to ensure that exceptions can be properly handled when they occur. By setting parameters in Redis, implementing atomic operations using Lua scripts, and combining the encapsulation of the utility class, idempotency control of tasks and barrier management are achieved, ensuring the correct execution of tasks and data consistency in a distributed environment.

[0096] In some embodiments, the method may further include: after the barrier connector object is created by the barrier connector class loader, the barrier connector object is placed in the unified environment, and the life cycle of the barrier connector object is managed through the unified environment.

[0097] Specifically, the barrier connector object is registered in a unified environment (such as the IOC container of the Spring framework). When the static method needs to use the barrier connector object, it obtains the object from the unified environment. The static method is used to provide general tool functions and does not depend on object instances. By obtaining the barrier connector object from the unified environment, the independence and generality of the static method can be maintained. It can also improve the maintainability and scalability of the code: when it is necessary to modify the creation and management method of the barrier connector object, only the modification needs to be made in the unified environment, which will not affect the implementation of the static method. The static method can be reused in different places, and the latest barrier connector object can be obtained from the unified environment each time it is used.

[0098] In some embodiments, the ways for the static method to obtain the barrier connector object from the unified environment include: configuration file reading, environment variable obtaining, and dependency injection.

[0099] Configuration file reading means storing the relevant configuration information (such as class name, parameters, etc.) of the barrier connector object in a configuration file. The static method obtains this information by reading the configuration file, and then creates or obtains the barrier connector object according to the configuration information. The configuration file formats include XML, JSON, Properties, etc.

[0100] Environment variable obtaining means setting the relevant information of the barrier connector object as environment variables. The static method obtains the values of the environment variables through the interfaces provided by the system, and then creates or obtains the barrier connector object according to these values. Environment variables are configuration information at the operating system level, and different operating systems have different setting and obtaining methods.

[0101] Dependency injection is a software design pattern. The barrier connector object is externally injected into the class where the static method that needs to use it is located. In this way, there will be a dependency injection container (such as the inversion of control IOC container of the Spring framework) to manage the life cycle and dependency relationship of the object. The static method can obtain the barrier connector object through the interfaces or annotations provided by the container.

[0102] In some embodiments, the method further includes: the basic platform class loader continues the parent delegation to the JVM class loader to obtain the jar package of the Redis basic connector, specifically including:

[0103] After receiving the class loading request from the barrier connector class loader, the basic platform class loader retrieves the connector index. If the jar package of the Redis basic connector corresponding to the class loading request cannot be obtained in the connector index, it continues the parent delegation to the JVM class loader to obtain the jar package of the Redis basic connector; wherein the jar package of the Redis basic connector is directly integrated in the task execution platform.

[0104] In this embodiment, the Redis basic connector is integrated into the platform's jar package and loaded by the topmost JVM class loader. The JVM application class loader adopts the parent delegation mechanism, which ensures the hierarchical structure and security of class loading. When classes related to the basic connector need to be loaded, the JVM class loader will first attempt to load them. First, it checks whether these classes have been loaded. If not, it will search for the corresponding bytecode files in the jar package according to the fully qualified names of the classes and load them into the JVM. Integrating the Redis basic connector into the platform's jar package and loading it by the JVM class loader can ensure that these key components are correctly loaded and initialized when the system starts. Since the JVM class loader is at the top of the class loading hierarchy, it has the highest priority and the widest access rights, and can load core system classes and key application components, thus ensuring the stability and normal operation of the entire system.

[0105] In this way, the classes and resources of the basic connector can be shared throughout the JVM process while being isolated from the classes and resources of other applications. Different application modules or plugins rely on the same basic connector. Loading by the JVM class loader can ensure that they use the same connector instance, avoiding version inconsistencies or resource conflicts caused by loading by different class loaders.

[0106] Concentrating the classes related to the basic connector in the jar package of the task execution platform and loading them by the JVM class loader is conducive to the unified management and maintenance of these classes. For example, when the basic connector needs to be upgraded, its vulnerabilities fixed, or its performance optimized, only the jar package of the task execution platform needs to be updated, rather than making individual modifications and deployments at each place where the connector is used, improving the maintainability and scalability of the system.

[0107] The beneficial effects of the embodiments of the present invention are as follows:

[0108] In the embodiments of the present invention, the barrier connector is used as a coordination center to ensure that multiple subtasks are executed in a specific order or under specific conditions. It can set barrier points, causing the subtasks to pause when they reach the barrier points and wait for other related subtasks to complete before continuing to execute together, avoiding queue blocking problems caused by inconsistent execution times and retry counts of multiple subtasks during task execution;

[0109] In the embodiment of the present invention, the basic platform class loader is used as the parent class loader of all connector class loaders. The related classes of the Redis connection pool client are used as the dependent packages of the platform itself and are loaded in the JVM class loader (alias "app") through the parent delegation mechanism. As a type of connector, the Redis basic connector's class loader depends on the basic platform class loader. During the loading process, following the hierarchical relationship of the class loaders and the parent delegation mechanism can ensure the uniqueness and consistency of classes throughout the Java application, avoiding conflicts and chaos caused by different class loaders loading the same class, and ensuring that the Redis basic connector can correctly use the classes of the Redis connection pool client to complete the interaction operations with the Redis database;

[0110] In the embodiment of the present invention, in order to ensure the uniqueness of classes in the connector index and avoid class conflicts, when packaging the jar package, the connector does not include the basic Redis connection pool client; by directly integrating the Redis connection pool client into the task execution platform packaging, the code and configuration of the Redis connection pool client can be independently managed and maintained. At the same time, it is also convenient to optimize and upgrade the functions of the connection pool without affecting the functions of other connectors.

[0111] In the embodiment of the present invention, by setting parameters in Redis, implementing atomic operations using Lua scripts, and combining the encapsulation of utility classes, the idempotency control and barrier management of tasks are realized, ensuring the correct execution of tasks and data consistency in a distributed environment.

[0112] Embodiment 2

[0113] As Figure 5 shown, the present invention provides a task execution device based on a dynamic class loading task execution platform. Among them, the task execution platform is as Figure 2 shown, including: a JVM class loader, a basic platform class loader with a connector index, a task class loader, a Redis basic connector, and a barrier connector class loader; the device includes:

[0114] A creation module, configured to create a static utility class containing static methods in the barrier connector, and encapsulate operations related to barriers and idempotency control in the static methods of the static utility class;

[0115] A trigger and delegation module, configured to, when a task of a class loading request loaded by the task class loader needs to be divided into multiple subtasks, call the static method of the static utility class in the barrier connector to trigger class loading, and through the class loading, trigger the parent delegation mechanism to delegate the class loading request to the basic platform class loader;

[0116] A retrieval module, which is used for the basic platform class loader to retrieve the connector index and obtain the barrier connector class loader corresponding to the class loading request;

[0117] A delegation and loading module, which is used for the barrier connector class loader to parent-delegate the class loading request to the basic platform class loader. The basic platform class loader continues to parent-delegate to the JVM class loader to load the jar package of the Redis basic connector, and load the Redis connection pool client class according to the jar package, and then return to the barrier connector class loader to create a barrier connector object;

[0118] A Redis connection module, which is used for the barrier connector object to establish a connection with Redis through the Redis connection pool client and interact with Redis through this connection;

[0119] A barrier and idempotency control module, which is used for the barrier connector object to call the static method and perform operations related to barrier and idempotency control through this static method.

[0120] In some embodiments, the Redis connection module specifically includes:

[0121] An acquisition sub-module, which is used to acquire a connection from the Redis connection pool client. The related classes of the Redis connection pool client are used as the dependent packages of the platform and are loaded in the JVM application class loader through parent delegation, and are used to implement connection management and resource allocation when the platform interacts with the Redis database;

[0122] A creation sub-module, which is used to create an instance of the Redis basic connector in the code logic of the barrier connector object or reference an existing instance of the Redis basic connector;

[0123] A call sub-module, which is used for the barrier connector object to call the methods provided by the Redis basic connector through the instance and interact with the Redis server according to the connection. The methods provided by the Redis basic connector include connection establishment, command execution, and connection management.

[0124] In some embodiments, the barrier and idempotency control module specifically includes:

[0125] The static method call sub-module is used to transfer the relevant parameters set in Redis to the static method of the static utility class when the barrier connector object calls the unlocking static method of the static utility class. The relevant parameters include the business identification number, sub-task number, number of sub-tasks, and application identification number for calling the barrier. Among them, the business identification number is used to uniquely identify a business operation or business process, and different business operations should have different business identification numbers. The number of sub-tasks is the number of sub-tasks into which the entire business operation is split. The sub-task number is used to identify the number of the currently executing sub-task. The application identification number for calling the barrier is used to uniquely identify the application instance that calls the barrier and distinguish different application instances in a distributed system.

[0126] The execution sub-module, the static method of the static utility class performs operations related to barrier and idempotency control according to the relevant parameters and the Lua script of Redis. Among them, the static methods include a try-lock method, an unlock method, and a cancel method.

[0127] In some embodiments, the execution sub-module is specifically used for:

[0128] Before executing the business code of each sub-task, call the try-lock method, and check the value at the position of the flag bit corresponding to each sub-task in the barrier through the Lua script. If the value at the position of the flag bit is 1, it is regarded as a failed lock. If the value at the position of the flag bit is not 1, check whether there is an idempotency lock. If there is an idempotency lock, it is regarded as a failed lock. If there is no idempotency lock, set the idempotency lock, set the value of the idempotency lock to the application identification number, and set the expiration time of the idempotency lock at the same time. If the lock is successfully acquired, execute the business code of the sub-task. If the lock acquisition fails, skip the subsequent processing of the sub-task.

[0129] Judge whether the business code of the sub-task is executed successfully. If it is executed successfully, call the unlock method, set the value at the position of the flag bit corresponding to the sub-task to 1 through the unlock method, and delete the idempotency lock. Check whether the values at all barrier positions are 1. If the values at all barrier positions are 1, it indicates that all relevant sub-tasks have been completed, execute the subsequent operations and jump out of the loop. If there are uncompleted sub-tasks, continue to wait for execution until the task ends. If it is not executed successfully, directly delete the idempotency lock.

[0130] If an exception occurs during the execution of the business code of the sub-task, perform a cancellation operation through the cancel method in the static method.

[0131] In some embodiments, it further includes a unified management sub-module, which is used to put the barrier connector object into a unified environment after the barrier connector class loader creates the barrier connector object, and manage the life cycle of the barrier connector object through the unified environment; the static method is used to obtain the barrier connector object from the unified environment.

[0132] In some embodiments, the ways for the static method to obtain the barrier connector object from the unified environment include: configuration file reading, environment variable obtaining, and dependency injection.

[0133] In some embodiments, the delegation and loading module is further used for: after the basic platform class loader receives the class loading request from the barrier connector class loader, it retrieves the connector index. If the jar package of the Redis basic connector corresponding to the class loading request cannot be obtained in the connector index, it continues to delegate to the JVM application class loader through the parent-child delegation to obtain the jar package of the Redis basic connector; wherein the jar package of the Redis basic connector is directly integrated in the task execution platform.

[0134] For the specific details of this task execution device, please refer to the method embodiments.

[0135] Embodiment 3

[0136] The embodiments of the present invention further provide a computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, it implements the task execution method of any one of the above task execution platforms based on dynamic class loading.

[0137] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, to implement all or part of the processes in the above-described embodiment methods of the present invention, it can also be completed by a computer program instructing relevant hardware. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, the steps of the above-described various method embodiments can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in the form of source code, object code, executable file, or some intermediate form, etc. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disc, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electrical carrier signal, telecommunication signal, and software distribution medium, etc. Of course, there are other ways of readable storage media, such as quantum memory, graphene memory, and so on. It should be noted that the content included in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electrical carrier signals and telecommunication signals.

[0138] Embodiment 4

[0139] The present invention also provides an electronic device. The electronic device according to the embodiment of the present invention includes: one or more processors; a storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the task execution method of a task execution platform based on dynamic class loading provided by the present invention. Next, refer to Figure 6 , which shows a schematic structural diagram of a computer system 500 of an electronic device suitable for implementing the embodiment of the present invention. Figure 6 The shown electronic device is only an example and should not impose any limitation on the functions and usage scope of the embodiment of the present invention.

[0140] As Figure 6As shown, the computer system 500 includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage section 508 into a random access memory (RAM) 503. In the RAM 503, various programs and data required for the operation of the computer system 500 are also stored. The CPU 501, ROM 502, and RAM 503 are connected to each other via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0141] The following components are connected to the I / O interface 505: an input section 506 including a keyboard, a mouse, etc.; an output section 507 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc. and a speaker, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card, a modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the I / O interface 505 as needed. A removable medium 511, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is mounted on the drive 510 as needed so that a computer program read from it is installed into the storage section 508 as needed.

[0142] Specifically, according to the embodiments disclosed in the present invention, the process described in the above main step diagram can be implemented as a computer software program. For example, an embodiment of the present invention includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program contains program codes for performing the method shown in the main step diagram. In the above embodiment, the computer program can be downloaded and installed from a network via the communication section 509, and / or installed from the removable medium 511. When the computer program is executed by the central processing unit 501, the above functions defined in the system of the present invention are executed.

[0143] It should be noted that the computer-readable medium shown in the present invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the above two. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of a computer-readable storage medium can include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium can be any tangible medium that contains or stores a program, and this program can be used by or in conjunction with an instruction execution system, apparatus, or device. In the present invention, a computer-readable signal medium can include a data signal propagated in a baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, and this computer-readable medium can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on a computer-readable medium can be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0144] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram can represent a module, a program segment, or a part of code, and the above module, program segment, or part of code contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks can occur in a different order than that marked in the accompanying drawings. For example, two consecutive blocks shown can actually be executed substantially in parallel, and they can sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and the combination of blocks in a block diagram or flowchart, can be implemented by a dedicated hardware-based system for performing the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0145] The units involved in the embodiments of the present invention can be implemented in software or in hardware. The described units can also be provided in a processor, and the names of these units do not, in some cases, constitute a limitation to the units themselves.

[0146] The above specific implementation manners do not constitute a limitation to the protection scope of the present invention. Those skilled in the art should understand that various modifications, combinations, sub - combinations and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A task execution method for a task execution platform based on dynamic class loading, characterized in that, The task execution platform includes: a JVM class loader, a basic platform class loader with a connector index, a task loader, a Redis basic connector, and a barrier connector; the method includes: Create a static utility class containing static methods in the barrier connector, and encapsulate operations related to barriers and idempotency control in the static methods of the static utility class; When the tasks in the class loading requests loaded by the task class loader need to be split into multiple subtasks, call the static method of the static utility class in the barrier connector to trigger class loading, and through the class loading, trigger the parent delegation mechanism to delegate the class loading request to the basic platform class loader; The basic platform class loader retrieves the connector index and obtains the barrier connector class loader corresponding to the class loading request; The barrier connector class loader delegates the class loading request to the basic platform class loader, and the basic platform class loader continues to delegate to the JVM class loader to load the jar package of the Redis basic connector, and load the relevant classes of the Redis connection pool client according to the jar package, and return to create a barrier connector object in the barrier connector class loader; The barrier connector object establishes a connection with Redis through the Redis connection pool client and interacts with Redis through the connection; The barrier connector object calls the static method and performs operations related to barriers and idempotency control through the static method; 2. The method according to claim 1, wherein The barrier connector object establishes a connection with Redis through the Redis connection pool client and interacts with Redis through the connection, specifically including: Obtain a connection from the Redis connection pool client, where the relevant classes of the Redis connection pool client are used as dependent packages of the platform and are loaded in the JVM class loader through parent delegation for connection management and resource allocation when the task execution platform interacts with the Redis database; Create an instance of the Redis basic connector in the code of the barrier connector object or reference an existing instance of the Redis basic connector; The barrier connector object calls the methods provided by the Redis basic connector through the instance and interacts with the Redis server according to the connection; the methods provided by the Redis basic connector include connection establishment, command execution, and connection management; 3. The method according to claim 1, wherein The barrier connector object calls the static method and performs operations related to barriers and idempotency control through the static method, specifically including: When the barrier connector object calls the unlock static method of the static utility class, it passes the relevant parameters set in Redis to the static method of the static utility class; the relevant parameters include a business identification number, a subtask number, the number of subtasks, and an application identification number for calling the barrier; The static method of the static utility class performs operations related to barriers and idempotency control according to the relevant parameters and the Lua script of Redis; among them, the static methods include a try lock method, an unlock method, and a cancel method.

4. The method according to claim 3, characterized in that, The static method of the static utility class performs operations related to barrier and idempotency control according to the relevant parameters and the Lua script of Redis, specifically including: Before executing the business code of each subtask, call the try-to-lock method. Check the value at the position of the flag bit corresponding to each subtask in the barrier through the Lua script. If the value at the position of the flag bit is 1, it is regarded as a failed lock. If the value at the position of the flag bit is not 1, then judge whether there is an idempotency lock. If there is an idempotency lock, it is regarded as a failed lock. If there is no idempotency lock, then set the idempotency lock, set the value of the idempotency lock to the application identification number, and set the expiration time of the idempotency lock at the same time. If the lock is successfully acquired, then execute the business code of the subtask. If the lock acquisition fails, then skip the subsequent processing of the subtask; Judge whether the business code of the subtask is successfully executed. If it is successfully executed, then call the unlock method. Through the unlock method, set the value at the position of the flag bit corresponding to the subtask to 1, and delete the idempotency lock. Check whether the values of all barrier positions are 1. If the values of all barrier positions are 1, it indicates that all related subtasks have been completed, execute the subsequent operations and jump out of the loop. If there are unfinished subtasks, then continue to wait for execution until the task ends. If it is not successfully executed, then directly delete the idempotency lock; If an exception occurs during the execution of the business code of the subtask, perform a cancellation operation through the cancellation method in the static method.

5. The method according to claim 1, characterized in that, The flag bit corresponding to each subtask in the barrier is stored in the data structure of Redis in the form of a bitmap.

6. The method according to claim 1, wherein The method further includes: after the barrier connector class loader creates a barrier connector object, put the barrier connector object into a unified environment, and manage the life cycle of the barrier connector object through the unified environment; The static method obtains the barrier connector object from the unified environment; The ways for the static method to obtain the barrier connector object from the unified environment include configuration file reading, environment variable acquisition, and dependency injection.

7. The method according to claim 1, wherein The method further includes: the basic platform class loader continues to delegate to the JVM class loader to obtain the jar package of the Redis basic connector, specifically including: After receiving the class loading request from the barrier connector class loader, the basic platform class loader retrieves the connector index. If the jar package of the Redis basic connector corresponding to the class loading request is not obtained in the connector index, then continue to delegate to the JVM class loader to obtain the jar package of the Redis basic connector. Among them, the jar package of the Redis basic connector is directly integrated in the task execution platform.

8. A task execution device of a task execution platform based on dynamic class loading, characterized in that, The task execution platform includes: JVM class loader, basic platform class loader with connector index, task loader, Redis basic connector, and barrier connector; The device includes: A creation module, which is used to create a static utility class containing static methods in the barrier connector, and encapsulate operations related to barriers and idempotency control in the static methods of the static utility class; A trigger and delegation module, which is used to call the static methods of the static utility class in the barrier connector to trigger class loading when a task of a class loading request loaded by a task class loader needs to be divided into multiple subtasks, and trigger the parent delegation mechanism through the class loading, and delegate the class loading request to the basic platform class loader; A retrieval module, which is used for the basic platform class loader to retrieve a connector index and obtain a barrier connector class loader corresponding to the class loading request; A delegation and loading module, which is used for the barrier connector class loader to delegate the class loading request to the basic platform class loader through parent delegation, and the basic platform class loader continues to delegate to the JVM class loader through parent delegation to load the jar package of the Redis basic connector, and load relevant classes of the Redis connection pool client according to the jar package, and return to the barrier connector class loader to create a barrier connector object; A Redis connection module, which is used for the barrier connector object to establish a connection with Redis through the Redis connection pool client and interact with Redis through the connection; A barrier and idempotency control module, which is used for the barrier connector object to call the static method and execute operations related to barriers and idempotency control through the static method.

9. An electronic device, characterized in that, Comprising: One or more processors; A storage device, which is used to store one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement a task execution method of a task execution platform based on dynamic class loading as described in any one of claims 1-7.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements a task execution method of a task execution platform based on dynamic class loading as described in any one of claims 1-7.

Citation Information

Patent Citations

  • Service implementation method and system, electronic equipment and storage medium

    CN114675834A

  • Method and apparatus for class intialization barriers and access to class variables in multitasking virtual machines

    US20020133527A1