Database driver hot loading method and device and electronic equipment

Abstract

The embodiment of the invention discloses a database driver hot loading method and device and electronic equipment. The method comprises the steps that a database drive loading request is obtained, the database drive loading request comprises a database drive file and parameter information, and the parameter information comprises the type of a target data source; querying historical adaptive data of the type of data source, and determining whether the database driving file is adaptive to the target data source or not based on the historical adaptive data and the parameter information; if so, generating a class isolation identifier for the database drive file, and performing byte code modification on a drive class in the database drive file based on the class isolation identifier to create a class loading space; and instantiating the target driving object in the class loading space, and updating a service route based on the target driving object so as to orient a connection request for the target data source to the target driving object. According to the embodiment, continuity and zero-interruption upgrading of business services are guaranteed, and the accuracy and reliability of adaptive decision between the driver and the data source are improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a database driver hot-loading method, apparatus, and electronic device. Background Technology

[0002] In the fields of big data and cloud computing, database drivers serve as the core bridge connecting applications and data sources, and their management and maintenance are crucial for ensuring stable system operation. Traditional driver management methods typically statically bind driver files to application code. Any driver update, rollback, or addition of data source support requires a series of operations, including code modification, recompilation, packaging and deployment, and service restart. This process is not only inefficient but also inevitably leads to business service interruptions, failing to meet the urgent needs of modern businesses for high availability and agile delivery.

[0003] In existing technologies, the compatibility between database drivers and data sources is usually judged by human experience, and static replacement of drivers is achieved by restarting the application. This approach has problems such as high driver adaptation error rate, conflicts when multiple driver versions are loaded in parallel, and business interruption caused by driver updates. Summary of the Invention

[0004] This application proposes a database driver hot-loading method, apparatus, and electronic device, which can realize conflict-free parallel loading and dynamic hot loading of multiple versions of database drivers, ensuring the continuity of business services and zero-interruption upgrades, and improving the accuracy and reliability of adaptation decisions between drivers and data sources.

[0005] In a first aspect, embodiments of this application provide a database driver hot-loading method, the method comprising: obtaining a database driver loading request, the database driver loading request including a database driver file and parameter information, the parameter information including the type of a target data source; querying historical adaptation data of the data source of the type, and determining whether the database driver file is compatible with the target data source based on the historical adaptation data and the parameter information; if compatible, generating a class isolation identifier for the database driver file, modifying the bytecode of the driver class in the database driver file based on the class isolation identifier to create a class loading space; instantiating a target driver object in the class loading space, and updating the business route based on the target driver object to direct connection requests to the target data source to the target driver object.

[0006] Secondly, embodiments of this application provide a database driver hot-loading apparatus, comprising: an acquisition unit, configured to acquire a database driver loading request, the database driver loading request including a database driver file and parameter information, the parameter information including the type of a target data source; a determination unit, configured to query historical adaptation data of the data source of the specified type, and determine whether the database driver file is compatible with the target data source based on the historical adaptation data and the parameter information; a creation unit, configured to generate a class isolation identifier for the database driver file if compatible, and modify the bytecode of the driver class in the database driver file based on the class isolation identifier to create a class loading space; and a loading unit, configured to instantiate a target driver object in the class loading space, and update the business route based on the target driver object to direct connection requests to the target data source to the target driver object.

[0007] Thirdly, embodiments of this application provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any embodiment of the first aspect.

[0008] Fourthly, embodiments of this application provide a computer-readable medium having a computer program stored thereon that, when executed by a processor, implements the method as described in any embodiment of the first aspect.

[0009] The database driver hot-loading method, apparatus, and electronic device provided in this application obtain a database driver loading request containing database driver files and parameter information, query historical adaptation data of data sources of the same type as the target data source, and determine whether the database driver file is compatible with the target data source based on the historical adaptation data and parameter information. This transforms driver compatibility judgment from relying on human experience to automated decision-making based on objective historical data, reducing subjective misjudgments and significantly improving the accuracy and reliability of driver-data source compatibility decisions. When compatibility is determined, a class isolation identifier is generated for the database driver file. Based on the class isolation identifier, the bytecode of the driver class in the database driver file is modified to create a class loading space. A unique class isolation identifier and an independent class loading environment are created for each driver version, physically isolating the runtime space of different versions of driver classes at the bytecode level. This avoids loading conflicts caused by identical class names, thereby achieving conflict-free parallel loading and execution of multiple versions of database drivers. By instantiating the target driver object in the class loading space and updating the business route based on the target driver object, connection requests to the target data source are directed to the target driver object. This enables the database driver to take effect simply by updating the business route, without restarting the application or service carrying the business. This achieves dynamic hot reloading of the database driver, ensuring the continuity of business services and zero-interruption upgrades. Attached Figure Description

[0010] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart of an embodiment of the database driver hot-loading method of this application; Figure 2 This is an exemplary system architecture diagram to which the database-driven hot-loading method of this application applies; Figure 3 This is a schematic diagram of an embodiment of the database-driven hot-loading device of this application; Figure 4 This is a schematic diagram of the structure of an electronic device used to implement the embodiments of this application. Detailed Implementation

[0011] All actions involving the acquisition of signals, information, or data in this application are carried out in accordance with the relevant data protection laws and policies of the country where the application is located, and with the authorization of the owner of the relevant device.

[0012] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0013] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0014] Please refer to Figure 1 The diagram illustrates a flow 100 of an embodiment of the database driver hot-loading method according to this application. This database driver hot-loading method can be applied to various electronic devices with data processing capabilities, such as cloud servers and physical servers. The execution entity of this database driver hot-loading method can be a processor in the aforementioned electronic device.

[0015] This database-driven hot-reload method includes the following steps: Step 101: Obtain the database driver loading request. The database driver loading request includes the database driver file and parameter information, including the type of the target data source.

[0016] In this embodiment, the database driver file refers to a Java archive (JAR) file that conforms to the Java Database Connectivity (JDBC) specification and is used to connect to a specific type of database. It contains driver implementation classes (such as com.mysql.cj.jdbc.Driver), dependency libraries, and metadata files, and is the physical form of the driver in the storage medium.

[0017] Parameter information refers to a set of configuration data specified by the user or identified by the system when initiating a driver loading request, used to describe the characteristics and loading strategy of the target data source. Besides including the type of the target data source, such as MySQL or PostgreSQL, parameter information may also include the version of the target data source, the version of the database driver file, and business priority, etc., without specific limitations here. Business priority can characterize the importance of the business carried by the target data source.

[0018] In this embodiment, delivery personnel can upload database driver files and edit parameter information through the visual "data source management interface" provided by the application layer, and then send a database driver loading request. After receiving the database driver loading request, the execution entity of the database driver hot-loading method can parse the request to obtain the database driver file and parameter information carried in the database driver loading request.

[0019] Taking "Adding a new PostgreSQL 16 data source driver (driver version 42.7.3)" as an example, delivery personnel can log in to the data source management interface through a browser and perform the following operations: select the target data source type, such as "PostgreSQL"; enter the target data source version, such as "16"; upload the local database driver file, such as postgresql-42.7.3.jar; and click "Submit Verification". This information is submitted to the backend via an AJAX request, constituting a database driver loading request.

[0020] Step 102: Query the historical adaptation data of this type of data source. Based on the historical adaptation data and parameter information, determine whether the database driver file is compatible with the target data source.

[0021] In this embodiment, historical adaptation data refers to a set of records that have been continuously accumulated and structured during past driver loading and operation. Each record may include a specific data source type, data source version, driver version, adaptation success rate, average connection time, common fault types, etc. For example, "The success rate of adapting PostgreSQL 15 to the 42.6.0 version database driver is 95%; the success rate of adapting to the 42.7.0 version database driver is 88%; the fault types include 'connection timeout' and 'SQL syntax incompatibility'."

[0022] Specifically, the target data source type can be used as an index to query historical compatibility data for data sources of the same type. Then, a decision logic is invoked to comprehensively analyze the parameter information and database driver file information of this request, and refer to the success and failure patterns in the historical records to determine whether it is compatible or not. Here, compatibility refers to the technical compatibility between the version and functionality of the database driver file and the version and protocol requirements of the target data source, ensuring a successful connection and stable execution of Structured Query Language (SQL) operations.

[0023] As an example, according to the query results, the success rate of combining PostgreSQL version 15 with driver version 42.6.0 in the past was 98%, while the combination with version 42.5.0 had experienced connection timeout failures. The current request for PostgreSQL version 16 with driver version 42.7.3, although not an exact match, can be logically determined to be compatible based on version evolution patterns and driver release notes.

[0024] In some alternative implementations, the compatibility between the database driver file and the target data source can be determined through the following sub-steps: Sub-step 1021: Generate feature vectors based on historical adaptation data and parameter information.

[0025] A feature vector is a one-dimensional ordered array of multiple features that represents the combination of the database driver file and the target data source. In practice, key fields such as data source version and driver version can be extracted from the parameter information, and quantitative historical performance indicators associated with these key fields, such as average success rate and common failure rate, can be retrieved and statistically analyzed from historical adaptation data. This information is then encoded into a fixed-dimensional numerical array to obtain the feature vector.

[0026] Sub-step 1022: Input the feature vector into the pre-trained fit evaluation model to obtain the fit score.

[0027] An adaptation evaluation model is a mathematical model that is pre-trained on a large amount of historical adaptation data using machine learning algorithms. It can be used to solve classification or regression problems, such as machine learning models based on logistic regression or random forests, or neural network models. The adaptation evaluation model has learned the latent mapping relationship between feature vectors and adaptation results, and can be used to predict the feature vectors of new inputs.

[0028] Specifically, the feature vector generated in sub-step 1021 can be used as input parameters to call the interface of the adaptation evaluation model already loaded into memory. Internally, the adaptation evaluation model performs forward calculations on the input parameters based on its trained weights and functions, such as the sigmoid function of a logistic regression model, and outputs a fitness score. The fitness score quantitatively reflects the probability or confidence that the adaptation evaluation model can successfully adapt the combination of the database driver file and the target data source.

[0029] Sub-step 1023: Based on the comparison results of the fit score and the preset threshold, determine whether the database driver file is compatible with the target data source.

[0030] The preset threshold is a pre-configured critical score, the specific value of which can be set as needed, for example, 85, without limitation here. Here, the fit score output by the fit evaluation model can be compared with the preset threshold. If the fit score is greater than or equal to the preset threshold, it can be determined that the database driver file is compatible with the target data source; otherwise, it can be determined that the database driver file is not compatible with the target data source, and the optimal data source version can be recommended.

[0031] Because the fit evaluation model is trained on a large number of real-world success and failure cases, it can uncover complex correlation patterns that are difficult for humans to detect and can handle feature combinations that are far more complex than those obtained manually. Therefore, using the fit evaluation model for fit judgment eliminates judgment biases caused by differences in personal experience. In addition, the entire process is completed automatically within milliseconds, which greatly shortens the time required for driving fit verification compared to the tens of minutes or even hours that manual research, testing, and verification might take, thus improving operational efficiency.

[0032] Step 103: If compatible, generate a class isolation identifier for the database driver file, and modify the bytecode of the driver class in the database driver file based on the class isolation identifier to create a class loading space.

[0033] In this embodiment, the class isolation identifier is a globally unique string identifier generated for each successful adaptation load. This identifier is logically strongly associated with the "data source type-version-driver version" combination, used to physically distinguish different versions of driver classes at the bytecode level. The class isolation identifier is used to uniquely identify and isolate the class loading space corresponding to a specific version of the database driver instance at the Java Virtual Machine (JVM) level. Its core function is to resolve naming conflicts between multiple driver versions, which is crucial for achieving parallel, conflict-free loading. For example: iso_pg16_001.

[0034] Bytecode modification refers to the technical process of reading, analyzing, and rewriting compiled Java Virtual Machine bytecode files (.class files), specifically referring to the modification of the bytecode structure of driver classes.

[0035] The class loading space refers to the independent namespace for class definitions defined by the Java class loader instance and its parent delegation chain. Classes loaded within this space are treated as completely different types in the JVM from classes with the same name loaded by other class loader instances, thus achieving runtime isolation.

[0036] In this embodiment, if step 102 determines that the system is compatible, a globally unique class isolation identifier, such as "iso_pg16_001", is first generated. Then, the database driver file, such as the aforementioned postgresql-42.7.3.jar file, is read, and the bytecode of the core driver class (such as org.postgresql.Driver) is located. Using a bytecode editing tool, without changing its functional logic, the class name is modified to org.postgresql.Driver_iso_pg16_001, thus appending the isolation identifier. Finally, a completely new, independent URL ClassLoader instance, i.e., a custom class loader instance, is created and used to load the modified class. This process constitutes the creation of the class loading space.

[0037] In some optional implementations, after generating a class isolation identifier for the database driver file, the following operations can also be performed: obtain the driver metadata used to manage this loading process, store the driver metadata in the driver metadata management module, and the driver metadata may include, but is not limited to, class isolation identifier, parameter information, and storage location information of the database driver file; use the parameter information and class isolation identifier as custom metadata of the database driver file, and store the database driver file and custom metadata in the object storage system.

[0038] Driver metadata refers to structured data describing the database driver file's own attributes, management strategies, and lifecycle states. Storage location information refers to the precise address of the database driver file in the object storage system. It typically consists of two parts: a bucket name and an object key. For example, the bucket name might be `driver-object`, and the object key might be `postgresql-42.7.3.jar`; together, they uniquely identify a stored object.

[0039] The driver metadata management module, referred to as DMMM, is an independent, centralized software component or service used for the persistent storage, querying, updating, and synchronization of driver metadata. The driver metadata management module provides highly available and strongly consistent data management capabilities.

[0040] Object storage systems are cloud storage services based on HTTP (Hypertext Transfer Protocol) or HTTPS (HTTP Secure) protocols, employing a flat namespace (bucket-object) architecture, and are specifically designed for storing unstructured data (such as files). Their core features include high scalability, high persistence, and rich metadata support. In practice, an object storage system can refer to a functionally enhanced MinIO-Plus component. MinIO-Plus is a driver-specific object storage component based on native MinIO extensions. Its core capabilities include: providing custom metadata interfaces required for driver management, supporting fields such as model scoring and class isolation identifiers; providing real-time event notification capabilities for driver file creation / update / deletion; and a built-in SHA-256 (Secure HashAlgorithm 256-bit) integrity verification mechanism.

[0041] Custom metadata is an extension mechanism provided by object storage systems, allowing users to append a set of user-defined key-value pairs when storing objects (files). This data is stored along with the object itself and can be read and written independently of the file content through the object storage API (Application Programming Interface). It is typically identified by a specific HTTP header prefix (such as x-amz-meta- in the AWS S3 protocol).

[0042] It should be noted that the driver metadata can also include other information as needed, such as compatibility scores and caching strategies, without specific limitations here.

[0043] By structuring key information in the driver lifecycle, such as class isolation identifiers, parameters, and storage locations, into driver metadata and centrally storing it in a dedicated driver metadata management module, the unification, centralization, and persistence of driver management information are achieved. Furthermore, by storing parameter information and class isolation identifiers as custom metadata along with the driver file in an integrated manner within the object storage system, event identifiability and process-driven functionality at the storage layer are achieved.

[0044] In some alternative implementations, the class loading space can be created through the following sub-steps: Sub-step 1031: Read the raw bytecode of the target driver class in the database driver file.

[0045] The target driver class refers to the core bootstrap class in the database driver JAR package. This class is the entry point for the JDBC API and is used to establish database connections. For example, in the PostgreSQL driver, the fully qualified name of this class is org.postgresql.Driver; in the MySQL driver, it is com.mysql.cj.jdbc.Driver. Modifying this class is key to resolving conflicts.

[0046] Raw bytecode refers to the binary instruction stream contained in a compiled Java class file (.class file) that conforms to the Java Virtual Machine Specification. It is the representation of Java source code at the JVM level, containing all information such as the class structure, fields, methods, and constant pool.

[0047] Specifically, the process begins by acquiring the JAR file. For example, the business routing module first downloads the database driver JAR package from the object storage system (MinIO-Plus) to a local temporary directory based on storage location information from event notifications or metadata. Then, the JAR package is parsed and its entries are traversed to locate the target driver class. For instance, the .class file entries corresponding to the target driver class are filtered out based on pre-defined rules (such as class name pattern matching *Driver.class). Typically, a JDBC driver JAR package contains only one class that directly implements the java.sql.Driver interface; this is the core target. Finally, the bytecode is extracted. For example, all the binary data from the located .class file entries is read into an array. This byte array is the raw bytecode.

[0048] Sub-step 1032 involves modifying the original bytecode using a bytecode editing framework, appending the class isolation flag to the class name of the target driver class, and obtaining the modified bytecode.

[0049] A bytecode editing framework is a library that provides APIs for dynamically analyzing, generating, and transforming Java bytecode. It allows direct manipulation of the binary content of .class files at runtime without accessing the source code. Bytecode editing frameworks can include, but are not limited to, Object Modeling Frameworks (ASM). ASM is a Java bytecode manipulation and analysis framework known for its small size, high performance, and flexibility; it provides fine-grained control over bytecode through the visitor pattern.

[0050] Appending to a class name is a bytecode transformation operation that modifies the constant entries in the constant pool representing the fully qualified class name, as well as all references to that class name. The result is a separator (such as an underscore "_") and a class isolation identifier appended to the original class name, forming a new, globally unique fully qualified name. For example, changing `org.postgresql.Driver` to `org.postgresql.Driver_iso_pg16_001`. The modified bytecode contains the bytecode instruction stream defining the new class name and adjusting all related references. This bytecode logically defines a new class whose identity (class object) in the JVM is completely different from the original class.

[0051] Specifically, the ASM framework's ClassReader can be used to read the raw bytecode, and a custom ClassVisitor subclass can be created. In its visit method, the received original class name parameter is concatenated with the class isolation flag to form a new class name, which is then passed to subsequent processing. The modified bytecode is then generated using ClassWriter.

[0052] Sub-step 1033: Create a custom class loader instance corresponding to the class isolation identifier.

[0053] A custom class loader instance refers to a class loader object created specifically for loading a particular isolated driver. Specifically, a dedicated class loader can be instantiated. During creation, a unique class isolation identifier (such as iso_pg16_001) is passed as a parameter to associate the loader with the specific driver version.

[0054] Sub-step 1034 loads the modified bytecode using a custom class loader instance to create a class loading space.

[0055] Specifically, you can call the `defineClass` method of the custom class loader instance created in the previous step, passing in the modified bytecode and the corresponding new class name (fully qualified name). This method will define a completely new class in the JVM, and this class will be bound to this class loader instance. Since each class isolation identifier corresponds to a unique class loader instance, an independent class loading space is created after successful loading.

[0056] By dynamically modifying the bytecode of the target driver class using the ASM bytecode editing framework, class isolation identifiers are physically woven into the fully qualified names of the classes. This makes the same driver class in different versions appear as two classes with completely different names at the binary level, thus bypassing the fundamental JVM restriction that prohibits defining classes with the same name under the same class loader. By creating and associating an independent custom class loader instance with each class isolation identifier, and having this instance load the corresponding modified bytecode, these driver classes with differentiated class names are further loaded into different, mutually isolated class loader namespaces. Even without modifying the class names, the JVM will treat classes defined by different class loaders as different classes, forming a double isolation guarantee. This enables parallel, conflict-free hot loading of multiple versions of database drivers. Step 104: Instantiate the target driver object in the class loading space, and update the business route based on the target driver object to direct connection requests to the target data source to the target driver object.

[0057] In this embodiment, the target driver object refers to a callable instance obtained by instantiating the loaded driver class in the class loading space through reflection. This object is the actual executor for the application to perform network connections and protocol interactions with the database.

[0058] Business routing can be represented by a global, in-memory mapping table (such as ConcurrentHashMap). This table uses the logical identifier of the target data source as the key and the target driver object instance to be used as the value, and is used to correctly distribute the application's data access requests to the corresponding driver instance.

[0059] Specifically, continuing the example above, within the class loading space created in step 103, a class named `org.postgresql.Driver_iso_pg16_001` can be loaded and instantiated via the Java Reflection API to obtain the target driver object. Next, the global driver instance mapping table in memory is updated, atomically replacing the old driver object reference with a reference to this newly instantiated target driver object for the key "PostgreSQL_16". For example, when the order microservice needs to establish a connection to the PostgreSQL 16 database again, its connection pool will query this global mapping table, obtain the new driver object instance based on the key "PostgreSQL_16", and use it to create the physical connection. Throughout this process, the order microservice process itself does not need to be restarted.

[0060] In some optional implementations, the parameter information also includes business priority, which characterizes the importance of the business carried by the target data source. Business priority can be set by the delivery personnel in the application layer interface, for example, "high" or "low". After instantiating the target driver object in the class loading space, the following steps can be performed: store the target driver object in a distributed cache cluster; configure the expiration time and active refresh frequency for the target driver object in the distributed cache cluster based on the business priority.

[0061] In this context, a distributed cache cluster refers to a distributed component used to cache frequently accessed driver instances, such as a Redis distributed cache cluster. A Redis distributed cache cluster can store data using "data source type_database driver version" as the key and can set dynamic expiration and refresh policies for drivers of different priorities, supporting high-concurrency calls. Expiration time refers to the lifespan set for each stored driver object in the distributed cache cluster. Active refresh frequency refers to the period at which a cached item is actively reloaded and updated before its natural expiration. For example, a 30-minute expiration time and active refresh every 5 minutes can be set for the database driver adapted to a data source with a "high" business priority; a 2-hour expiration time and active refresh every 30 minutes can be set for the database driver adapted to a data source with a "low" business priority.

[0062] Specifically, after the business routing module instantiates the driver via reflection, a custom serialization tool can be called to serialize the target driver object into a byte array. Then, using a Redis client, the serialized value is stored in the cache using "data source type_database driver version" as the key. In storage operations (such as `setex`), the appropriate expiration time parameter is passed according to the business priority, and a scheduled task (such as `ScheduledExecutorService`) is used to periodically reload the driver and update the cache.

[0063] By serializing the instantiated target driver object and storing it in a Redis distributed cache cluster, the most time-consuming steps in the driver loading process, such as disk / network I / O, JAR parsing, class loading, and object initialization, are transformed into one-time preprocessing. This allows all subsequent calls to the driver to be converted into high-speed read operations on memory, thereby reducing the latency of a single driver loading and achieving an order-of-magnitude performance improvement.

[0064] By introducing business priorities and directly influencing the expiration time and active refresh frequency of driver objects in the cache, cache resources can be allocated differentially based on the actual importance of the business carried by the data source. Driver instances corresponding to high-priority businesses ensure extremely high availability and data freshness through shorter expiration times and more frequent active refreshes; low-priority businesses use longer expiration times, reducing unnecessary system overhead, thereby achieving optimal allocation of cache resources and intelligent balancing of system load overall.

[0065] In some alternative implementations, the target-driven object can be updated to the business route via the following sub-steps: Sub-step 1041: Establish the mapping relationship between the target data source and the target driving object.

[0066] Sub-step 1042: Based on the mapping relationship, update the global driver instance mapping table so that the target driver object can handle the connection request after receiving a connection request for the target data source.

[0067] The global driver instance mapping table is a global, thread-safe data structure (such as a ConcurrentHashMap) used to store the mapping relationship between all active data sources and driver objects. It is the core routing table for driver request distribution. The global driver instance mapping table can be maintained by the business routing module. In this step, this mapping table can be updated, for example, establishing a mapping relationship between PostgreSQL_16 and the newly created target driver object. After updating this table, when all new connection requests targeting this data source arrive at the business routing module, the module can retrieve the corresponding target driver object by querying this table and use it to create a database connection.

[0068] Sub-step 1043: Send a driver ready notification to the business service associated with the target data source.

[0069] A connection request refers to a request initiated by a business service to obtain a database connection in order to access a target data source. A business service refers to the backend application service that actually uses the database driver to connect to and operate the data source, such as the "order system" or "user system." Here, a driver readiness notification can be broadcast to all business services (such as the order service and user service) using the PostgreSQL_16 data source via a messaging mechanism (such as WebSocket). In practice, the business routing module can proactively push status change messages to all business services using the target data source through a real-time, bidirectional network communication channel, informing them that the new driver is ready.

[0070] By establishing a mapping relationship between the target data source and the target driver object, and updating the global driver instance mapping table in the business routing module, the driver object lookup logic is centralized and atomic. By sending real-time driver readiness notifications to related business services, a low-latency, event-driven communication mechanism is established between the event producer (business routing module) and the consumer (business service) of the driver update. This achieves a closed loop for the database driver hot update process.

[0071] In some optional implementations, after updating the global driver instance mapping table, the following steps can also be performed: retain the original driver object associated with the target data source and the class loading space corresponding to the original driver object for a preset time; within the preset time, if an abnormality is detected in the target driver object, roll back the mapping relationship in the global driver instance mapping table to the original driver object, and notify the business service to switch back to the original driver object.

[0072] The original driver object refers to the older version driver instance associated with the target data source that was in use in the business routing prior to this hot reload update. For example, when updating the PostgreSQL 16 driver from version 42.6.0 to 42.7.3, the driver instance corresponding to version 42.6.0 is the original driver object. Runtime exceptions may include, but are not limited to, connection failures and SQL execution errors. Rollback refers to the operation of restoring the driver configuration state to its pre-update state when the target driver object encounters a runtime exception; specifically, it involves restoring the routing mapping relationship to point to the original driver object.

[0073] Specifically, while the business routing module updates the global driver instance mapping table, it does not immediately destroy or release references to the original driver object and its class loading space. Instead, it keeps it accessible in memory (or through caching) and starts a timer or delayed task corresponding to a preset duration. Within the preset duration, the health status of the target driver object is continuously monitored. Once an anomaly is detected, such as an excessive connection failure rate, a rollback process is immediately triggered. At the same time, an emergency notification can be sent to relevant business services via channels such as WebSocket, requesting them to switch back to the old driver instance.

[0074] By retaining the original driver object and its class loading space in memory for a preset duration after driver updates, a deterministic and readily available safe recovery point is created for each hot reload operation. This ensures that after introducing a new driver version, the system is not in an unprotected single-point-of-failure state, but rather has a verified and usable backup state. This solves the fundamental flaw of traditional hot update solutions where, if a new version fails, the old version has already been overwritten or uninstalled, making rapid recovery impossible and requiring complex and time-consuming full rollbacks or even restarts to resolve the issue.

[0075] The method provided in the above embodiments of this application, by obtaining a database driver loading request containing database driver files and parameter information, querying historical adaptation data of data sources of the same type as the target data source, and determining whether the database driver file is compatible with the target data source based on the historical adaptation data and parameter information, transforms driver compatibility judgment from relying on human experience to automated decision-making based on objective historical data, reducing subjective misjudgments and thus significantly improving the accuracy and reliability of driver-data source compatibility decisions. When compatibility is determined, by generating a class isolation identifier for the database driver file, and modifying the bytecode of the driver class in the database driver file based on the class isolation identifier to create a class loading space, a unique class isolation identifier and an independent class loading environment are created for each driver version. This physically isolates the runtime space of different versions of driver classes at the bytecode level, avoiding loading conflicts caused by identical class names, thereby achieving conflict-free parallel loading and execution of multiple versions of database drivers. By instantiating the target driver object in the class loading space and updating the target driver object to the business route, connection requests from the target data source are directed to the target driver object. This allows the database driver to take effect simply by updating the business route, without restarting the application or service carrying the business. This achieves dynamic hot reloading of the database driver, ensuring the continuity of business services and zero-interruption upgrades.

[0076] In conjunction with one or more of the above embodiments, see Figure 2 This illustrates an exemplary system architecture 200 to which the database-driven hot-loading method of this application is applicable. For example... Figure 2 As shown, the system architecture may include an application layer, a decision layer, a storage-caching layer, and an execution layer.

[0077] The application layer serves as the visual interaction entry point between delivery personnel and the system. Its core component is the "data source management interface," which provides visual support for the entire lifecycle of driver operations. It allows delivery personnel to upload drivers (selecting local JDBC driver JAR packages), configure basic parameters (data source type such as PostgreSQL, data source version such as 16, business priority such as "high / low"), view status (driver adaptation progress, loading status), and perform rollback operations (switching to the old version in case of an anomaly) through a browser. All operations are linked with the decision-making layer in real time through AJAX (Asynchronous JavaScript and XML) requests, without the need for coding or compilation intervention, reducing the operational threshold for delivery personnel and achieving "zero technical threshold" interaction for driver management.

[0078] The decision-making layer is responsible for driver adaptation judgment and metadata lifecycle management, and consists of an intelligent adaptation decision engine (which can be referred to as IDE) and a driver metadata management module (DMMM).

[0079] The Intelligent Adaptation Decision Engine (IDE) is used to automatically adapt database drivers to target data sources based on a pre-trained adaptation evaluation model. The adaptation evaluation model can be trained on a large amount of historical adaptation data and can use a logistic regression model. The Intelligent Adaptation Decision Engine first obtains historical adaptation data (such as data source version, driver version, adaptation success rate, and failure type) of the target data source (e.g., PostgreSQL) from the Driver Metadata Management Module (DMMM). Then, it constructs a feature vector based on the current parameters to be adapted (data source version, driver version, and historical average success rate), and inputs the feature vector into the model to obtain an adaptation score. This engine supports iterative model updates to adapt to newer data sources such as PostgreSQL 16.

[0080] The Driver Metadata Management Module (DMMM) stores fine-grained driver metadata, such as adaptation model scores, class isolation identifiers, caching strategies, and fault recovery logs. It supports real-time synchronization with MinIO-Plus and Redis. For example, MinIO-Plus automatically synchronizes metadata when the driver file is updated, and provides metadata for reloading when the Redis cache expires, solving the problems of metadata disconnect from files and chaotic version tracking in traditional solutions.

[0081] The storage-caching layer provides persistent storage and high-frequency caching for driver files and instances, with dual support, consisting of MinIO-Plus (enhanced object storage) and a Redis distributed cache cluster.

[0082] MinIO-Plus extends driver-specific capabilities on top of the native MinIO, including: a driver metadata interface that supports custom fields such as x-amz-meta-db-type and x-amz-meta-class-isolation-id, and can be linked with DMMM; a real-time event notification module that can listen for driver file creation / update / deletion events and automatically send notifications to the business routing module; a SHA-256 integrity verification mechanism that can automatically calculate and compare hash values ​​during file upload and loading to prevent tampering or corruption; and the creation of a dedicated "driver-object" bucket with IAM (Identity and Access Management) permissions configured, for example, allowing only system service accounts to perform s3:GetObject (get object) / s3:PutObject (place object) operations to ensure driver file security.

[0083] Redis distributed caching clusters can accelerate caching for high-frequency driver instances (e.g., ≥100 calls per day). The cache key can be designed as "data source type_database driver version" (e.g., pg16_42.7.3), and the value is the serialized driver instance object. It can dynamically configure caching strategies according to business priorities and reduce the pressure on MinIO-Plus access through caching, reduce driver loading latency, and support high-concurrency calls.

[0084] The execution layer may include an ASM bytecode enhancement class loader and a business routing module. The execution layer is responsible for driving instantiation, class isolation loading, and smooth business switching, and consists of the ASM bytecode enhancement class loader and the business routing module.

[0085] The ASM bytecode enhanced class loader can be developed based on the ASM bytecode framework. When loading a driver, it can dynamically modify the bytecode of the JDBC core class: read the core class (such as org.postgresql.Driver) in the driver JAR package, parse the bytecode through ClassReader, and append a class isolation identifier to the class name (such as changing it to org.postgresql.Driver_iso_pg16_001) through ClassVisitor. At the same time, it creates an independent class loading space for each isolation identifier, avoiding the class overriding problem caused by the traditional ClassLoader parent delegation mechanism, and realizing zero-conflict parallel loading of multiple versions of drivers.

[0086] The business routing module can receive MinIO-Plus event notifications and trigger the driver loading process. It instantiates the modified driver class through reflection and synchronizes it to the Redis cache. It can update the global driver instance mapping table (ConcurrentHashMap) to store the new instance and send a switching notification to business services (such as the order system and user system) via WebSocket. This enables a smooth transition when new requests use the new instance and old requests complete transactions, while retaining the old instance for a certain period of time, such as 24 hours. In case of an exception, it can roll back within 100ms to ensure business continuity.

[0087] The following example demonstrates how to add a new PostgreSQL 16 data source driver (driver version 42.7.3) using the four-layer architecture described above. The specific process is as follows: The first step is to submit the driver loading request. Delivery personnel log in to the "Data Source Management Interface" via a browser, go to the "Driver Management → Add Driver" module, and configure basic parameters: select the data source type "PostgreSQL", enter the data source version "16", and select the business priority "High" from the dropdown menu; then upload the driver file: click "Select File" to upload the local PostgreSQL driver JAR package (filename "postgresql-42.7.3.jar"); submit the request: click "Submit Verification", and the interface sends the parameters (data source type, version, business priority, file information) to the decision-making IDE via an AJAX request, simultaneously triggering the MinIO-Plus bucket initialization process.

[0088] Step 2: MinIO-Plus bucket preprocessing. First, bucket existence is verified, for example, checking if the "driver-object" bucket exists. Then, bucket creation and permission configuration are performed: if the bucket does not exist, it is created, and a private access policy is configured; if the bucket already exists, the "bucket ready" status is returned directly.

[0089] The third step is driver adaptation scoring and strategy recommendation. After receiving the application layer parameters, the IDE works in conjunction with the DMMM to complete the adaptation decision. First, it obtains historical adaptation data, such as "PostgreSQL 15 adaptation to driver 42.6.0 has a success rate of 95%, adaptation to driver 42.7.0 has a success rate of 88%, and the failure types include "connection timeout" and "SQL syntax incompatibility". Then, based on parameter information such as "dbVersion=16, driverVersion=42.7.3, historyAvgSuccessRate=92%", it constructs a feature vector, inputs it into the model, and outputs an adaptation score, such as "92 points" (≥85 points is considered passing). After that, it generates a "verification passed" result, synchronously recommends a caching strategy (e.g., 30-minute expiration, refresh every 5 minutes), and returns it to the application layer in JSON format. The interface displays "Adaptation passed, file upload will be executed soon".

[0090] Step 4: Driver file MD5 pre-verification. After receiving feedback from the IDE, the application layer performs a duplicate file verification to avoid redundant uploads. Specifically, it calculates the MD5 value of "postgresql-42.7.3.jar" (e.g., "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6"). Then, it performs metadata comparison. For example, it calls the relevant MinIO-Plus interface, iterates through objects in the bucket prefixed with "postgresql-", and reads the custom metadata fields of each object. If a matching MD5 value exists, the interface displays "This version of the driver already exists; no need to upload again," and proceeds directly to step 6; otherwise, it executes step 5.

[0091] Step 5: Drive file upload and metadata configuration. The application layer calls the MinIO-Plus file upload interface (such as the putObject interface) to perform file upload and configures custom metadata. After successful upload, MinIO-Plus returns a unique identifier for the object (such as "obj-pg16-4273"). The application layer records the identifier and triggers DMMM to synchronize metadata.

[0092] Step 6: After receiving the successful upload notification from MinIO-Plus, DMMM generates driver metadata and synchronizes it to the associated components. Specifically, it generates JSON-formatted metadata, including fields such as driver unique identifier, class isolation identifier, caching strategy, and MinIO storage information. Then, cross-component synchronization occurs, meaning data is synchronized between MinIO-Plus and MySQL respectively.

[0093] Step 7: MinIO-Plus event notification configuration. Specifically, after DMMM synchronizes metadata, it calls the MinIO-Plus event configuration interface to set the driver loading trigger mechanism. After configuration, MinIO-Plus returns an "Event notification enabled" status, and the loading process of the business routing module will be automatically triggered when a new object is added to the "driver-object" bucket.

[0094] Step 8: The business routing module initializes the ASM class loader. After receiving the MinIO-Plus event notification, the business routing module starts loading preparation: first, it extracts metadata, then initializes the class loader, and finally downloads the driver file.

[0095] Step nine involves performing bytecode enhancement and class loading on the downloaded JAR package using the ASM class loader. First, core classes are filtered. Then, the bytecode of these classes is read using ASM's ClassReader, a ClassVisitor subclass is created, and the visit method is overridden. The class name is changed to "org.postgresql.Driver_iso_pg16_001" (adding a class isolation identifier), and isolation logging is injected into the visitMethod method. Afterward, the modified bytecode is generated using ClassWriter, the class is loaded into an independent class space, and the loaded Class object is returned.

[0096] Step 10: Driver Instantiation and Redis Caching. The business routing module instantiates the driver based on the loaded Class object, specifically by using reflection to call the driver class's parameterless constructor to generate the driver instance. Simultaneously, it synchronizes with the Redis cache: first, Redis cache configuration is performed, then it is refreshed periodically by loading the instance from MinIO-Plus and updating the Redis cache to ensure instance validity.

[0097] Step 11: Business Route Switching and Instance Activation. After the business routing module completes caching, it performs a smooth business switch. Specifically, it first updates the global instance, then notifies the business services, and then performs a smooth switch. Newly initiated database connection requests automatically use the new instance, while old requests continue to use the old instance until the current transaction is completed, avoiding business interruption.

[0098] Step 12: Retaining and Releasing Expired Old Instances. After the business routing module switches to a new instance, it manages the old instance to ensure rollback capability. Specifically, this includes recording the old instance, configuring delayed release (such as removing global references, releasing class space, deleting Redis cache, etc.), and triggering rollback in case of exceptions.

[0099] Through the above architectural design, driver compatibility judgment can be transformed from relying on human experience to automated decision-making based on objective historical data, reducing subjective misjudgments and significantly improving the accuracy and reliability of compatibility decisions between drivers and data sources. Simultaneously, it avoids loading conflicts caused by identical class names, thus enabling conflict-free parallel loading and execution of multiple versions of database drivers. Furthermore, it eliminates the need to restart the application or service hosting the business, achieving dynamic hot reloading of database drivers and ensuring the continuity of business services and zero-disruption upgrades.

[0100] Further reference Figure 3 As an implementation of the methods shown in the above figures, this application provides an embodiment of a database-driven hot-loading device, which is similar to... Figure 1 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0101] like Figure 3As shown, the database driver hot-loading device 300 of this embodiment includes: an acquisition unit 301, used to acquire a database driver loading request, the database driver loading request including a database driver file and parameter information, the parameter information including the type of the target data source; a determination unit 302, used to query historical adaptation data of the data source of the type, and determine whether the database driver file is compatible with the target data source based on the historical adaptation data and the parameter information; a creation unit 303, used to generate a class isolation identifier for the database driver file if compatible, and modify the bytecode of the driver class in the database driver file based on the class isolation identifier to create a class loading space; and a loading unit 304, used to instantiate a target driver object in the class loading space, and update the business route based on the target driver object to direct the connection request to the target data source to the target driver object.

[0102] In some optional implementations of this embodiment, the determining unit 302 is further configured to: generate a feature vector based on the historical adaptation data and the parameter information; input the feature vector into a pre-trained adaptation evaluation model to obtain an adaptation score; and determine whether the database driver file is adapted to the target data source based on the comparison result of the adaptation score and a preset threshold.

[0103] In some optional implementations of this embodiment, the device further includes a storage unit, configured to: acquire driver metadata for managing the current loading process; store the driver metadata in a driver metadata management module, wherein the driver metadata includes the class isolation identifier, the parameter information, and the storage location information of the database driver file; use the parameter information and the class isolation identifier as custom metadata of the database driver file; and store the database driver file and the custom metadata in an object storage system.

[0104] In some optional implementations of this embodiment, the creation unit 303 is further configured to: read the original bytecode of the target driver class in the database driver file; modify the original bytecode through a bytecode editing framework, appending the class isolation identifier to the class name of the target driver class to obtain the modified bytecode; create a custom class loader instance corresponding to the class isolation identifier; and load the modified bytecode through the custom class loader instance to create the class loading space.

[0105] In some optional implementations of this embodiment, the parameter information further includes a business priority, which is used to characterize the importance of the business carried by the target data source; the device further includes a configuration unit, used to: store the target driver object in a distributed cache cluster; and configure an expiration time and active refresh frequency for the target driver object in the distributed cache cluster based on the business priority.

[0106] In some optional implementations of this embodiment, the loading unit 304 is further configured to: establish a mapping relationship between the target data source and the target driver object; update the global driver instance mapping table based on the mapping relationship so that the target driver object can process the connection request after receiving a connection request for the target data source; and send a driver ready notification to the business service associated with the target data source.

[0107] In some optional implementations of this embodiment, the device further includes a rollback unit, configured to: retain the original driver object associated with the target data source and the class loading space corresponding to the original driver object for a preset duration; within the preset duration, if an abnormal operation of the target driver object is detected, roll back the mapping relationship in the global driver instance mapping table to the original driver object, and notify the business service to switch back to the original driver object.

[0108] The apparatus provided in the above embodiments of this application, by acquiring a database driver loading request containing database driver files and parameter information, querying historical adaptation data of data sources of the same type as the target data source, and determining whether the database driver file and the target data source are compatible based on the historical adaptation data and parameter information, can transform driver compatibility judgment from relying on human experience to automated decision-making based on objective historical data, reducing subjective misjudgments and thus significantly improving the accuracy and reliability of the adaptation decision between the driver and the data source. When compatibility is determined, by generating a class isolation identifier for the database driver file, and modifying the bytecode of the driver class in the database driver file based on the class isolation identifier to create a class loading space, a unique class isolation identifier and an independent class loading environment are created for each driver version. This physically isolates the runtime space of different versions of driver classes at the bytecode level, avoiding loading conflicts caused by identical class names, thereby achieving conflict-free parallel loading and execution of multiple versions of database drivers. By instantiating the target driver object in the class loading space and updating the target driver object to the business route, connection requests from the target data source are directed to the target driver object. This allows the database driver to take effect simply by updating the business route, without restarting the application or service carrying the business. This achieves dynamic hot reloading of the database driver, ensuring the continuity of business services and zero-interruption upgrades.

[0109] The following is for reference. Figure 4 It shows a schematic diagram of the structure of an electronic device used to implement some embodiments of this application. Figure 4 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this application.

[0110] like Figure 4 As shown, electronic device 400 may include a processing device (e.g., a central processing unit, a graphics processor, etc.) 401, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 402 or a program loaded from storage device 408 into random access memory (RAM) 403. RAM 403 also stores various programs and data required for the operation of electronic device 400. Processing device 401, ROM 402, and RAM 403 are interconnected via bus 404. Input / output (I / O) interface 405 is also connected to bus 404.

[0111] Typically, the following devices can be connected to I / O interface 405: input devices 406 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 407 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 408 including, for example, disks, hard disks, etc.; and communication devices 409. Communication device 409 allows electronic device 400 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 An electronic device 400 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 4 Each box shown can represent a device or multiple devices as needed.

[0112] In particular, according to some embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of 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 communication device 409, or installed from storage device 408, or installed from ROM 402. When the computer program is executed by processing device 401, it performs the functions defined above in the methods of some embodiments of this application.

[0113] It should be noted that the computer-readable medium described in some embodiments of this application may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, 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 device, magnetic storage device, or any suitable combination thereof. In some embodiments of this application, a 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, apparatus, or device. In some embodiments of this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0114] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0115] The aforementioned computer-readable medium may be included within the aforementioned electronic device; or it may exist independently without being assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: obtain a database driver loading request, the database driver loading request including a database driver file and parameter information, the parameter information including the type of the target data source; query historical adaptation data for that type of data source, and based on the historical adaptation data and parameter information, determine whether the database driver file is compatible with the target data source; if compatible, generate a class isolation identifier for the database driver file, modify the bytecode of the driver class in the database driver file based on the class isolation identifier to create a class loading space; instantiate a target driver object in the class loading space, and update the business route based on the target driver object to redirect connection requests to the target data source to the target driver object.

[0116] Computer program code for performing operations of some embodiments 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, or it can be connected to an external computer (e.g., via the Internet using an Internet service provider), including local area networks (LANs) or wide area networks (WANs).

[0117] 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.

[0118] The units described in some embodiments of this application can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor may be described as including a first determining unit, a second determining unit, a selecting unit, and a third determining unit. The names of these units do not necessarily limit the specific unit itself.

[0119] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0120] The above description is merely a selection of preferred embodiments of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this application.

Claims

1. A database-driven hot-loading method, characterized in that, The method includes: Obtain a database driver loading request, the database driver loading request including a database driver file and parameter information, the parameter information including the type of the target data source; Query historical adaptation data of the data source of the aforementioned type, and based on the historical adaptation data and the parameter information, determine whether the database driver file is compatible with the target data source; If compatible, a class isolation identifier is generated for the database driver file, and the bytecode of the driver class in the database driver file is modified based on the class isolation identifier to create a class loading space; Instantiate a target driver object in the class loading space, and update the business route based on the target driver object to direct connection requests to the target data source to the target driver object.

2. The method according to claim 1, characterized in that, The step of determining whether the database driver file is compatible with the target data source based on the historical adaptation data and the parameter information includes: Based on the historical adaptation data and the parameter information, a feature vector is generated; The feature vector is input into a pre-trained fit evaluation model to obtain a fit score; Based on the comparison result between the adaptability score and the preset threshold, it is determined whether the database driver file is compatible with the target data source.

3. The method according to claim 1, characterized in that, After generating the class isolation identifier for the database driver file, the method further includes: Obtain the driver metadata used to manage this loading process, and store the driver metadata in the driver metadata management module. The driver metadata includes the class isolation identifier, the parameter information, and the storage location information of the database driver file. The parameter information and the class isolation identifier are used as custom metadata in the database driver file, and the database driver file and the custom metadata are stored in the object storage system.

4. The method according to claim 1, characterized in that, The step of modifying the bytecode of the driver class in the database driver file based on the class isolation identifier to create a class loading space includes: Read the raw bytecode of the target driver class in the database driver file; The original bytecode is modified by using a bytecode editing framework, and the class isolation identifier is appended to the class name of the target driver class to obtain the modified bytecode; Create a custom class loader instance corresponding to the class isolation identifier; The modified bytecode is loaded using the custom class loader instance to create the class loading space.

5. The method according to claim 1, characterized in that, The parameter information also includes a service priority, which is used to characterize the importance of the service carried by the target data source. After instantiating the target driver object in the class loading space, the method further includes: Store the target driver object in a distributed cache cluster; Based on the business priority, the expiration time and active refresh frequency are configured for the target driver object in the distributed cache cluster.

6. The method according to claim 1, characterized in that, The process of updating the service route based on the target driver object includes: Establish a mapping relationship between the target data source and the target driving object; Based on the mapping relationship, the global driver instance mapping table is updated so that the target driver object can handle the connection request after receiving a connection request for the target data source. Send a driver ready notification to the business service associated with the target data source.

7. The method according to claim 6, characterized in that, After updating the global driver instance mapping table, the method further includes: The original driver object associated with the target data source and the class loading space corresponding to the original driver object are retained for a preset duration; If an abnormal operation of the target driver object is detected within the preset time period, the mapping relationship in the global driver instance mapping table will be rolled back to the original driver object, and the business service will be notified to switch back to the original driver object.

8. A database-driven hot-loading device, characterized in that, The device includes: The acquisition unit is used to acquire a database driver loading request, wherein the database driver loading request includes a database driver file and parameter information, and the parameter information includes the type of the target data source. The determining unit is used to query historical adaptation data of the data source of the type, and determine whether the database driver file is compatible with the target data source based on the historical adaptation data and the parameter information; A creation unit is used to generate a class isolation identifier for the database driver file if adapted, and to modify the bytecode of the driver class in the database driver file based on the class isolation identifier to create a class loading space; The loading unit is used to instantiate a target driver object in the class loading space and update the business route based on the target driver object so as to direct connection requests to the target data source to the target driver object.

9. An electronic device, characterized in that, include: One or more processors; Storage device, on which one or more programs are stored, When the one or more programs are executed by the one or more processors, the one or more processors implement the method 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 program is executed by the processor, it implements the method as described in any one of claims 1-7.

Images