A service object dynamic configuration method
By dynamically collecting data and making quantitative decisions, the optimal storage mode is adaptively selected, solving the problem of balancing structural flexibility and query performance in complex business scenarios using traditional technologies, and enabling uninterrupted changes and efficient queries.
Patent Information
- Application Number
- CN202610289454.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-03-11
- Publication Date
- 2026-07-24
AI Technical Summary
When faced with complex business scenarios involving frequent changes and high-concurrency queries, existing technologies struggle to balance structural flexibility with query performance. The traditional EAV model has bottlenecks in query performance, while structured relational tables can affect business continuity when the structure changes.
By collecting characteristic parameters of business objects, normalizing them, and calculating the Configuration Flexibility Index (CFI) and Performance Degradation Index (PDM), the semantic storage mode (SSM) or the structured storage mode (CSM) is dynamically selected. Combined with two-stage batch query and bytecode generation, non-stop changes are achieved.
It achieves a balance between high performance and flexibility in scenarios with high concurrency queries and frequent changes. By dynamically selecting storage modes, it improves query performance and ensures business continuity.
Smart Images
Figure CN122450650A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of storage resource management technology, and more specifically to a method for dynamic configuration of business objects. Background Technology
[0002] In the process of enterprise informatization construction, the dynamic configuration capability of business objects has become a key indicator for measuring the flexibility and adaptability of a system. To cope with frequent changes in business attributes, existing technologies have mainly developed two paths: one is the unstructured storage solution represented by the Entity-Attribute-Value (EAV) model, which achieves dynamic expansion of business attributes by separating data rows from metadata, typically a dynamic ontology storage system; the other is the structured storage solution centered on relational tables, which ensures data consistency and query performance through predefined table structures and Object Relational Mapping (ORM) technology. However, both of these technologies face insurmountable bottlenecks in practical applications. While EAV-based systems possess extremely high structural flexibility, they require a large number of table join operations in multi-attribute combined query scenarios. As data scales, the number of database interactions increases exponentially, leading to prolonged response times and excessive consumption of CPU and memory resources, making it difficult to meet the real-time response requirements of high-concurrency scenarios. On the other hand, while structured relational table-based solutions have advantages in query performance, whenever the structure of a business object changes, it usually requires system downtime to perform data definition language operations and redeploy the application, a process that often lasts for several hours, severely impacting business continuity. Although the industry has proposed technologies such as index optimization, materialized views, and dynamic schema management to try to improve the above problems, these solutions are limited to local optimization within a single technical path and have never been able to achieve a fundamental balance between structural flexibility and query performance. When faced with complex business scenarios that have both frequent changes and high-concurrency query characteristics, existing technologies still lack a mechanism that can adaptively select the optimal storage architecture based on the actual operating status of the system. Summary of the Invention
[0003] To address complex business scenarios characterized by frequent changes and high-concurrency queries, this invention proposes a dynamic configuration method for business objects, comprising the following steps: S1: Collect characteristic parameters of the target business object, including the data scale and number of attributes obtained by querying the database, the frequency of structural changes obtained by analyzing system logs, and the query frequency and response time requirements obtained by performance monitoring. S2: Normalize the feature parameters in the application server memory, and then sum the normalized parameters according to preset weights to calculate the Configuration Flexibility Index (CFI) and Performance Degradation Index (PDM). S3: Based on the comparison results of CFI and PDM with preset thresholds, select either Semantic Storage Mode (SSM) or Structured Storage Mode (CSM) as the storage mode for the current business object based on preset quantitative decision. S4: When SSM is selected, a two-stage batch query is executed. In the first stage, a connection is obtained through the database connection pool and the query is executed to obtain the entity ID set in batch. In the second stage, the prepared statement is reused on the same database connection to query the corresponding attribute values in batch with the entity ID set as the condition. Then, the query results are reorganized into complete business objects in the application server memory. S5: When CSM is selected, data definition language statements are generated based on metadata and executed in database transactions to create or change the database table structure. At the same time, a bytecode generation framework is used to generate entity class bytecode corresponding to the table structure in the application server memory and load it into the JVM through a custom class loader. If any step in the above process fails, a rollback operation is triggered.
[0004] This invention dynamically collects business characteristics and makes quantitative decisions, adaptively selecting the optimal storage mode. This improves query performance while enabling non-stop changes to the business object structure, balancing the system's flexibility and high-performance requirements.
[0005] Furthermore, in step S2, the normalization interval parameters used for normalization processing and the preset weights used for calculating CFI and PDM are stored as configuration items in the configuration center or metadata table, and are loaded at runtime through the configuration center API or database query interface, supporting scenario-based version management and gray-scale rollback.
[0006] Furthermore, in step S2, the normalization process uses MinMax normalization, which specifically maps the actual values of each feature parameter to the range of (0,1) determined by the normalization interval parameter. The weights used in calculating CFI include data size weight, number of attributes weight, and change frequency weight; the weights used in calculating PDM include data size weight, number of attributes weight, query frequency weight, and response time requirement weight. Each weighting coefficient is determined through at least one of the following methods: historical data regression analysis, A / B test performance optimization, or expert experience configuration.
[0007] Furthermore, in step S3, the preset thresholds include a data size threshold, a change frequency threshold, and a response time threshold. The preset quantification decision is specifically as follows: When the data size is less than the first threshold and the change frequency is greater than the second threshold, the conditions for selecting SSM are met. When the data size is greater than the third threshold or the response time requirement is less than the fourth threshold, the conditions for selecting CSM are met. For business objects located in the boundary region, the storage mode is determined by comparing the utility function values calculated by CFI and PDM.
[0008] Furthermore, in step S4, when querying attribute values in batches using the entity ID set as a condition in the second stage, if the size of the entity ID set exceeds the preset batching threshold, the entity ID set is split into multiple subsets, and batch queries are performed on each subset. Finally, the query results of each batch are merged and recombined into a complete business object in the application server memory.
[0009] Furthermore, in step S5, when generating entity class bytecode in the application server memory using the bytecode generation framework, entity class bytecode conforming to the JPA specification is dynamically constructed based on the field names, data types, lengths, and constraint information in the metadata. The generation process is completed in the JVM heap memory.
[0010] Furthermore, in step S5, when executing data definition language statements to create or change the database table structure, the table structure change is achieved using shadow tables with atomic renaming operations or online DDL tools.
[0011] Furthermore, in step S5, when loading entity class bytecode using a custom class loader, a class loader with a version identifier is generated for each release, and after successful release and when the old version class has no active references, the class metadata in JVM memory is reclaimed by triggering the unloading of the class loader; if class loading fails, a rollback operation is triggered.
[0012] Furthermore, in step S5, the rollback operation includes: When a data definition language statement fails to execute, the data definition language statement operation is rolled back and the database connection is released. When class loading fails, roll back the executed data definition language statements and clean up the generated bytecode and custom class loader references.
[0013] Furthermore, in extreme scenarios involving extremely large data volumes, extremely high query frequencies, or extremely high change frequencies, a forced selection strategy is pre-configured in the configuration center. When characteristic parameters exceed the normal range, either CSM or SSM is directly selected based on a preset load strategy, and a monitoring alarm is triggered. After the system load returns to normal, the dynamic selection mechanism based on preset quantitative decisions is restored. The preset load strategy is specifically as follows: When the data size exceeds the first extreme threshold or the query frequency exceeds the second extreme threshold, select CSM directly; When the change frequency exceeds the third extreme threshold, select SSM directly.
[0014] Compared with the prior art, the present invention has at least the following beneficial effects: (1) The present invention proposes a dynamic configuration method for business objects. First, by collecting characteristic parameters such as data scale, number of attributes, change frequency, query frequency and response time requirements, the configuration flexibility index (CFI) and performance degradation index (PDM) are generated based on the normalization of configurable weights. These are used as objective quantitative basis to automatically select the optimal storage mode. (2) When the semantic storage mode SSM is selected, the massive JOIN operation in the traditional EAV mode is transformed into two fixed interactions of "batch ID retrieval - batch attribute value retrieval" through two-stage batch query. Combined with connection reuse and pre-compiled statements, the number of database interactions, CPU memory usage and connection pool pressure are reduced, and the response time is accelerated. (3) When the structured storage modality CSM is selected, the release is achieved without downtime through runtime bytecode generation and atomic table structure changes, which shortens the release time, and is equipped with versioned class loading and full-link rollback mechanisms to ensure business continuity; (4) Dynamic management of weight parameters and threshold rules is achieved through the configuration center, and a forced selection strategy is preset for extreme scenarios, so that the system can always maintain the best resource utilization and response performance under complex and ever-changing business loads. Attached Figure Description
[0015] Figure 1 A flowchart illustrating the steps of a dynamic configuration method for a business object. Detailed Implementation
[0016] The following are specific embodiments of the present invention, which are described in conjunction with the accompanying drawings to further illustrate the technical solutions of the present invention. However, the present invention is not limited to these embodiments.
[0017] In contemporary enterprise information systems, especially in environments employing microservice architecture and cloud-native deployments, the definition and structure of business objects often require rapid iteration to adapt to ever-changing market demands. For example, during e-commerce promotional periods, products may need to have attributes such as "pre-sale deposit" and "estimated delivery time" added temporarily; while in the financial risk control field, there are extremely stringent requirements for query latency of transaction records. Traditional data persistence solutions, whether using entity-attribute-value (EAV) model relational tables or strictly defined structured relational tables, struggle to achieve a perfect balance between the two core requirements of "structural flexibility" and "query performance." While the EAV model allows for flexible addition and deletion of attributes without modifying the database table structure, it requires numerous self-join operations during queries, leading to a sharp performance drop; while structured relational tables offer excellent query performance, any minor structural changes can result in prolonged database locking and application downtime, severely impacting business continuity. This invention aims to solve this long-standing technical challenge in enterprise information system construction by proposing a method that dynamically and adaptively selects the optimal storage and processing mode based on the actual operational characteristics of business objects, such as... Figure 1 As shown, the method mainly includes the following steps: S1: Collect characteristic parameters of the target business object, including the data scale and number of attributes obtained by querying the database, the frequency of structural changes obtained by analyzing system logs, and the query frequency and response time requirements obtained by performance monitoring. S2: Normalize the feature parameters in the application server memory, and then sum the normalized parameters according to preset weights to calculate the Configuration Flexibility Index (CFI) and Performance Degradation Index (PDM). S3: Based on the comparison results of CFI and PDM with preset thresholds, select either Semantic Storage Mode (SSM) or Structured Storage Mode (CSM) as the storage mode for the current business object based on preset quantitative decision. S4: When SSM is selected, a two-stage batch query is executed. In the first stage, a connection is obtained through the database connection pool and the query is executed to obtain the entity ID set in batch. In the second stage, the prepared statement is reused on the same database connection to query the corresponding attribute values in batch with the entity ID set as the condition. Then, the query results are reorganized into complete business objects in the application server memory. S5: When CSM is selected, data definition language statements are generated based on metadata and executed in database transactions to create or change the database table structure. At the same time, a bytecode generation framework is used to generate entity class bytecode corresponding to the table structure in the application server memory and load it into the JVM through a custom class loader. If any step in the above process fails, a rollback operation is triggered.
[0018] The core of this invention lies in treating business objects as dynamic entities with different lifecycle characteristics, rather than as static data structures. This method first uses a series of techniques embedded in the system to collect real-time or near-real-time characteristic parameters of the target business object. These parameters are not abstract mathematical variables, but rather digital mappings of the system's runtime state.
[0019] Specifically, the data size *n* is obtained by querying the total number of records for a specific business object in the entity table, reflecting the total number of instances of that business object in the current system. The number of attributes *m* is obtained by querying the number of attribute definition records for that business object in the metadata table, representing the complexity of the business object's structure. Structure change frequency. This is obtained through real-time analysis of system logs, especially database DDL operation logs. For example, by monitoring application server logs using log collection tools, keyword matching is used to identify operation statements such as "modify table structure" or "create new table," and the frequency of these statements is counted within a sliding time window, thereby quantifying the severity of changes to the business object structure. Query frequency and response time requirements This data originates from real-time data from performance monitoring systems. For example, monitoring tools can pull metrics such as the number of API calls and average response time from the application's JMX interface. This directly reflects the access pressure experienced by the business object and its sensitivity to user experience. The collection of these characteristic parameters forms the foundation of the entire dynamic configuration method, enabling it to perceive the true operational status of the business object.
[0020] After obtaining the aforementioned feature parameters, this method does not simply apply a few fixed rules, but introduces a quantitative decision-making model tightly coupled with the system architecture, performing a series of calculations in the application server's memory. Considering the significant scale differences between different business systems, directly comparing raw values is meaningless. Therefore, the collected raw parameters first need to be normalized, mapping them to a unified and comparable scale. The normalization process uses the Min-Max method; for example, the normalized value of the data size n... It is derived by calculating the ratio of the difference between the current value and the minimum value to the difference between the maximum and minimum values. The normalized interval parameter here is, for example... and These parameters are not arbitrarily set, but stored as system configuration items in the configuration center or metadata table. They can be derived through observation and fitting of historical data; for example, analyzing the scale of all business objects over the past year and taking the 5th and 95th percentiles as the minimum and maximum values. Alternatively, they can be initially configured by operations experts based on hardware capabilities and SLA requirements. These parameters, along with the various weighting coefficients used in subsequent calculations, can be dynamically loaded at runtime via the configuration center API or database query interface. This means the entire decision-making model has the ability to self-adjust and canary releases. The normalized parameters, combined with the weighting coefficients loaded from the configuration center, are weighted and summed in the JVM heap memory to calculate the Configuration Flexibility Index (CFI) and the Performance Degradation Index (PDM).
[0021] Taking CFI as an example, its calculation formula Taking into account the normalized data size Number of attributes and frequency of change Each of these is assigned a different weight. Among them, the data size weight... Attribute quantity weight and change frequency weight The design is aimed at a small data size ( Small, many attributes ( Large and frequently changing ( Larger business objects tend to have higher CFI values, leading the system to determine that these objects are more suitable for storage models that prioritize flexibility. Similarly, the formula for calculating PDM is: Data size weights here Attribute quantity weight Query frequency weight And response time requirement weight This is aimed at a large data scale ( Large), high query frequency ( Large), response time ( For small, demanding business objects, the PDM value will be high, indicating that if they are placed in the EAV model, there will be a serious performance degradation, thus tending to choose a high-performance storage mode.
[0022] Determining these weighting coefficients is a technical task in itself. They can be obtained through multiple linear regression analysis of historical operating data, or through A / B testing to compare the system performance under different weighting combinations in a real operating environment and select the optimal one.
[0023] It is worth noting that all normalized interval parameters, weighting coefficients, and decision thresholds involved in this invention are designed as configurable items that can be dynamically managed through a configuration center or metadata table. This means that system operators can flexibly adjust the sensitivity and bias of the decision model according to the actual needs of different business lines and environments (such as development, testing, and production), and even according to different stages of business development. For example, in the early stages of business deployment, the weight of change frequency can be appropriately increased to make the system more inclined to choose the SSM mode to cope with frequent changes in demand; as the business matures and the data scale increases, the weight can be gradually adjusted to make the system lean towards the CSM mode to pursue better query performance. This configurability makes the method of this invention not only applicable to a single system, but also a general and portable data persistence framework that can be applied in different business scenarios.
[0024] Based on the calculated CFI and PDM, the method proceeds to the final decision-making stage. The decision rules are based on a set of preset thresholds stored in the configuration center, such as a first threshold for data size (e.g., 100,000), a second threshold for change frequency (e.g., 5 times / month), a third threshold for data size (e.g., 200,000), and a fourth threshold for response time (e.g., 200ms). When a business object meets the condition of "data size less than the first threshold and change frequency greater than the second threshold," such as a startup business module in a rapid iteration phase, the system determines that it is suitable for the Semantic Storage Mode (SSM). Conversely, when a business object meets the condition of "data size greater than the third threshold or response time requirement less than the fourth threshold," such as a bank's core transaction log, the system determines that it is suitable for the Structured Storage Mode (CSM). For business objects in the boundary region, such as those with a data size of 150,000 and moderate change and query frequencies, the method introduces a utility function for refined decision-making. The utility function combines the values of CFI and PDM, automatically selecting the optimal solution by comparing the utility values under different modes. The entire decision-making process is completed instantly in the application server's memory, and the result will directly affect the routing of subsequent data access requests.
[0025] When the decision outcome leads to SSM (Structured Streaming Model), it means that the current business object's requirement for structural flexibility outweighs the need for extreme query performance. The system will then employ a two-stage batch query method tailored for this scenario. This method is key to solving the query performance bottleneck of the traditional EAV (Entity-Enterprise-Entity) model. Traditional EAV queries require multiple JOIN operations to assemble a business object with multiple attributes; the number of database interactions is directly proportional to the product of the number of entities and attributes. When querying a large number of entities, each containing many attributes, this can result in a massive number of JOIN operations, undoubtedly consuming huge amounts of database resources. The two-stage query proposed in this invention completely changes this model.
[0026] In the first stage, the query request executes a lightweight query that only operates on the entity table index through a connection obtained from the database connection pool. Its goal is to quickly obtain a list of all entity identifiers that meet the conditions, completely avoiding association with a large attribute value table.
[0027] In the second phase, the application utilizes the entity identifier list obtained in the first phase to execute a batch query using the same identifier list as filtering criteria on the same database connection, reusing the same pre-compiled database access object. This retrieves all attributes and their values corresponding to all these entities from the attribute value table at once. The key here is "same connection" and "reuse." By completing all operations within a single database session, the overhead of acquiring and releasing connections is significantly reduced, lowering connection pool occupancy from several times the baseline to near-baseline levels. Simultaneously, the reuse of pre-compiled statements also reduces the burden of database SQL parsing.
[0028] If the list of entity identifiers becomes very large, exceeding the safe threshold of the database or application memory, this method automatically splits the list into multiple smaller batches, repeating the second-stage query described above for each batch. After all batches of query results are returned, the application server efficiently reassembles complete business objects in memory, using entity identifiers and attribute identifiers as keys. In this way, regardless of the number of attributes in a business object, the number of database interactions in a typical query is kept consistently at a very low level (usually two, slightly more if necessary). The complexity of database interactions drops dramatically from being proportional to the product of the number of entities and attributes to a near-constant level, achieving the performance improvement of the EAV model.
[0029] When the decision result leads to CSM, it indicates that the current business object has a bias towards query performance. The system will adopt a completely different processing logic, namely the runtime release method, to solve the technical problem of downtime required for changes to the traditional relational table schema structure.
[0030] When it's necessary to add one or more attributes to a business object, this method first dynamically generates a standard statement to modify the database table structure based on information such as field names, data types, lengths, and constraints defined in the metadata database. For example, it might add a new field of a specific type to a specified data table. After generating the statement, the system executes it within a database transaction to change the underlying database table structure. To ensure uninterrupted business operations during the change process, advanced techniques such as shadow tables with atomic renaming or online DDL tools are employed. For instance, a shadow table with the same structure as the original table but containing the new field can be created. The data from the original table is synchronized to the shadow table, and finally, an atomic table renaming operation completes the switch between the old and new tables. The entire process is virtually imperceptible to the upper-layer application.
[0031] When the database structure is successfully changed, the application layer entity classes also need to be updated accordingly. The traditional approach involves modifying code, recompiling, packaging, and deploying—a lengthy process that requires system downtime. This invention, however, uses a bytecode generation framework, such as ByteBuddy or ASM, to dynamically generate JPA entity class bytecode that perfectly matches the new database table structure directly in the application server's JVM heap memory. The bytecode generation process dynamically constructs class attributes, access methods, and object-relational mapping annotations based on field definitions in the metadata, completely bypassing disk I / O and the traditional compile-deployment process. After bytecode generation, the system loads this bytecode into the JVM using a carefully designed custom class loader. This custom class loader generates an instance with a unique version identifier for each release, effectively avoiding class name conflicts and supporting the temporary coexistence of different versions of the same business object entity class in the JVM.
[0032] The atomicity of the entire runtime deployment process is guaranteed by a robust rollback mechanism. If a failure occurs during the database table structure modification phase, such as due to insufficient database permissions or field name conflicts, the transaction will automatically roll back, and the database structure will remain unchanged. If a failure occurs during the bytecode generation or class loading phase, such as when the generated bytecode does not conform to the JVM specification, the rollback mechanism will be triggered immediately. It will first execute the recorded reverse table structure modification operations, such as removing newly added fields, to undo the database-level changes; subsequently, it will clean up the generated bytecode data in memory and sever all references to the failed custom class loader, making it reclaimable.
[0033] Through this series of operations, it is ensured that in any abnormal situation, the system can be rolled back to the consistent state before release, with business applications completely unaware of the changes, achieving a zero-downtime structural change. After successful release and the old version of the entity class no longer has any active business threads or cached references, the system can also release the class metadata memory it occupies by calling the class loader's unloading mechanism, in conjunction with the JVM's garbage collection, thus achieving proper resource management.
[0034] To address system stability in extreme scenarios, this method also incorporates a load balancing strategy based on a configuration center. When the monitoring system detects that the data size of a business object exceeds a preset first extreme threshold or the query frequency exceeds a second extreme threshold, the system determines that the overhead of fine-grained decision-making may affect core stability, thus triggering a mandatory strategy. It directly selects the CSM mode with the best query performance and issues an alert. Conversely, when the change frequency exceeds a third extreme threshold, to avoid potential risks to the database from frequent online DDL operations, the system directly selects the most flexible SSM mode. Once the system load returns to normal and the monitoring indicators fall back below the thresholds, the system automatically exits the mandatory mode and reverts to the dynamic selection mechanism based on CFI and PDM quantitative decision-making, ensuring robustness under extreme conditions and optimal performance under normal conditions.
[0035] As can be seen from the above embodiments, the dynamic configuration method for business objects proposed in this invention exhibits excellent adaptability and stability under different business characteristics and operating environments. In scenarios with small data scales and frequent changes, the two-stage batch query mechanism effectively compensates for the performance shortcomings of the EAV model; in scenarios with large data scales and high query pressure, the runtime deployment mechanism injects necessary flexibility into the relational table model. More importantly, the existence of the quantitative decision-making model makes this model selection no longer static and one-off, but dynamically adjusted with changes in business characteristics, realizing continuous optimization of system resources. In summary, this invention has achieved significant technical progress in multiple dimensions such as database interaction efficiency, structural change response speed, and system resource utilization, providing a persistent solution for the construction of enterprise information systems that combines flexibility and high performance.
[0036] In summary, the proposed method for dynamic configuration of business objects first collects characteristic parameters such as data scale, number of attributes, change frequency, query frequency, and response time requirements. Based on the normalization of configurable weights, it generates a configuration flexibility index (CFI) and a performance degradation index (PDM), which serve as objective quantitative criteria to automatically select the optimal storage mode.
[0037] When the semantic storage modality (SSM) is selected, the massive JOIN operations in the traditional EAV mode are transformed into two fixed interactions of "batch ID retrieval - batch attribute value retrieval" through two-stage batch queries. Combined with connection reuse and prepared statements, the number of database interactions, CPU and memory usage and connection pool pressure are reduced, and the response time is accelerated.
[0038] When the Structured Storage Mode (CSM) is selected, non-stop deployment is achieved through runtime bytecode generation and atomic table structure changes, shortening the deployment time. Versioned class loading and full-link rollback mechanisms are also provided to ensure business continuity.
[0039] The configuration center enables dynamic management of weight parameters and threshold rules, and presets forced selection strategies for extreme scenarios, so that the system can always maintain optimal resource utilization and response performance under complex and ever-changing business loads.
[0040] It should be noted that all directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of the present invention are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indication will also change accordingly.
[0041] Furthermore, in this invention, descriptions involving terms such as "first," "second," and "a" are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.
[0042] In this invention, unless otherwise explicitly specified and limited, the terms "connection," "fixed," etc., should be interpreted broadly. For example, "fixed" can mean a fixed connection, a detachable connection, or an integral part; it can mean a mechanical connection or an electrical connection; it can mean a direct connection or an indirect connection through an intermediate medium; it can mean the internal communication of two components or the interaction between two components, unless otherwise explicitly limited. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.
[0043] Furthermore, the technical solutions of the various embodiments of the present invention can be combined with each other, but only if they are feasible for those skilled in the art. If the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.
Claims
1. A method for dynamically configuring business objects, characterized in that, Including the following steps: S1: Collect characteristic parameters of the target business object, including the data scale and number of attributes obtained by querying the database, the frequency of structural changes obtained by analyzing system logs, and the query frequency and response time requirements obtained by performance monitoring. S2: Normalize the feature parameters in the application server memory, and then sum the normalized parameters according to preset weights to calculate the Configuration Flexibility Index (CFI) and Performance Degradation Index (PDM). S3: Based on the comparison results of CFI and PDM with preset thresholds, select either Semantic Storage Mode (SSM) or Structured Storage Mode (CSM) as the storage mode for the current business object based on preset quantitative decision. S4: When SSM is selected, a two-stage batch query is executed. In the first stage, a connection is obtained through the database connection pool and the query is executed to obtain the entity ID set in batch. In the second stage, the prepared statement is reused on the same database connection to query the corresponding attribute values in batch with the entity ID set as the condition. Then, the query results are reorganized into complete business objects in the application server memory. S5: When CSM is selected, data definition language statements are generated based on metadata and executed in database transactions to create or change the database table structure. At the same time, a bytecode generation framework is used to generate entity class bytecode corresponding to the table structure in the application server memory and load it into the JVM through a custom class loader. If any step in the above process fails, a rollback operation is triggered.
2. The method for dynamically configuring business objects as described in claim 1, characterized in that, In step S2, the normalization interval parameters used for normalization processing and the preset weights used for calculating CFI and PDM are stored as configuration items in the configuration center or metadata table, and are loaded at runtime through the configuration center API or database query interface, supporting scenario-based version management and gray-scale rollback.
3. The method for dynamically configuring business objects as described in claim 2, characterized in that, In step S2, the normalization process uses MinMax normalization, which specifically maps the actual values of each feature parameter to the range of (0,1) determined by the normalization interval parameter. The weights used in calculating CFI include data size weight, number of attributes weight, and change frequency weight; The weights used when calculating PDM include data size weight, number of attributes weight, query frequency weight, and response time requirement weight; Each weighting coefficient is determined through at least one of the following methods: historical data regression analysis, A / B test performance optimization, or expert experience configuration.
4. The method for dynamically configuring business objects as described in claim 1, characterized in that, In step S3, the preset thresholds include a data size threshold, a change frequency threshold, and a response time threshold. The preset quantification decision is specifically as follows: When the data size is less than the first threshold and the change frequency is greater than the second threshold, the conditions for selecting SSM are met. When the data size is greater than the third threshold or the response time requirement is less than the fourth threshold, the conditions for selecting CSM are met. For business objects located in the boundary region, the storage mode is determined by comparing the utility function values calculated by CFI and PDM.
5. The method for dynamically configuring business objects as described in claim 1, characterized in that, In step S4, when querying attribute values in batches using the entity ID set as a condition in the second stage, if the size of the entity ID set exceeds the preset batching threshold, the entity ID set is split into multiple subsets, and batch queries are performed on each subset. Finally, the query results of each batch are merged and recombined into a complete business object in the application server memory.
6. The method for dynamically configuring business objects as described in claim 1, characterized in that, In step S5, when the bytecode generation framework generates entity class bytecode in the application server's memory, it dynamically constructs entity class bytecode that conforms to the JPA specification based on the field names, data types, lengths, and constraint information in the metadata. The generation process is completed in the JVM heap memory.
7. The method for dynamically configuring business objects as described in claim 1, characterized in that, In step S5, when executing data definition language statements to create or change the database table structure, the table structure change is achieved using shadow tables with atomic renaming operations or online DDL tools.
8. The method for dynamically configuring business objects as described in claim 1, characterized in that, In step S5, when loading entity class bytecode using a custom class loader, a class loader with a version identifier is generated for each release. After successful release and when the old version class has no active references, the class metadata in JVM memory is reclaimed by triggering the unloading of the class loader. If class loading fails, a rollback operation is triggered.
9. The method for dynamically configuring business objects as described in claim 1, characterized in that, In step S5, the rollback operation includes: When a data definition language statement fails to execute, the data definition language statement operation is rolled back and the database connection is released. When class loading fails, roll back the executed data definition language statements and clean up the generated bytecode and custom class loader references.
10. The method for dynamically configuring business objects as described in claim 1, characterized in that, When the business object involves extreme scenarios with extremely large data volumes, extremely high query frequencies, or extremely high change frequencies, a forced selection strategy is pre-configured in the configuration center. When the characteristic parameters exceed the normal range, either CSM or SSM is directly selected based on the preset load strategy, and a monitoring alarm is triggered. After the system load returns to normal, the dynamic selection mechanism based on preset quantitative decision-making is restored. The preset load strategy is specifically as follows: When the data size exceeds the first extreme threshold or the query frequency exceeds the second extreme threshold, select CSM directly; When the change frequency exceeds the third extreme threshold, select SSM directly.