Database request processing method and apparatus, computer device, computer-readable storage medium, and computer program product

Abstract

This application relates to a database request processing method, apparatus, computer device, computer-readable storage medium, and computer program product. The method includes: receiving a data query request sent by a terminal through a gateway; sending the data query request to a corresponding target database, and continuously monitoring the target database's response to the data query request for a target duration; wherein the target duration is less than the gateway's timeout threshold; if no query result is received from the target database within the target duration, sending a termination request to the target database and returning a prompt message to the terminal. This method, through a full-link interruption mechanism, ensures that once a request timeout is determined, the application server thread, database connection, and internal database resources are immediately released, effectively preventing cascading failures under high concurrency.

Description

Technical Field

[0001] This application relates to the field of computer data processing technology, and in particular to a database request processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] As enterprise applications evolve towards cloud-native and microservice architectures, the complexity of database query operations is increasing daily. Long-running query scenarios such as report generation, large-scale data filtering, and multi-table join analysis have become commonplace. In these scenarios, web application systems generally adopt a four-tier architecture of "client-gateway-application server-database".

[0003] In related technologies, the general process for handling complex database queries is as follows: the client initiates an HTTP request, which is forwarded to the application server through a gateway; the application server's main processing thread receives the request, obtains a database connection, and sends an SQL query command to the database; the gateway layer is configured with a fixed timeout threshold. If the database query takes longer than this threshold, the gateway forcibly disconnects the connection with the client and returns a 504 Gateway Timeout error. This approach suffers from resource leaks and zombie task accumulation issues in high-concurrency or data-intensive scenarios. Summary of the Invention

[0004] Therefore, it is necessary to provide a database request processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve the efficiency of database request processing in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a database request processing method, the method comprising:

[0006] The receiving terminal sends a data query request through the gateway; the data query request is used to request a data query in the database.

[0007] The data query request is sent to the corresponding target database, and the response of the target database to the data query request is monitored for a continuous target duration; wherein, the target duration is less than the timeout duration threshold of the gateway; the timeout duration threshold is used to characterize the maximum waiting time of the gateway before disconnecting the connection with the terminal if no response result of the data query request is received.

[0008] If no query result is received from the target database in response to the data query request within the target time period, a termination request is sent to the target database and a prompt message is returned to the terminal; wherein, the termination request is used to request the target database to stop executing the data query request; the prompt message includes an indication of the query timeout status of the data query request and a reconstruction suggestion for the data query request.

[0009] Secondly, this application also provides a database request processing apparatus, comprising:

[0010] The receiving module is used to receive data query requests sent by the terminal through the gateway; the data query requests are used to request data queries in the database.

[0011] The monitoring module is used to send the data query request to the corresponding target database and start monitoring the response of the target database to the data query request for a continuous target duration; wherein, the target duration is less than the timeout duration threshold of the gateway; the timeout duration threshold is used to characterize the maximum waiting time of the gateway before disconnecting the connection with the terminal when no response result of the data query request is received;

[0012] The sending module is configured to send a termination request to the target database and return a prompt message to the terminal if no query result is received from the target database for the data query request within the target time period; wherein, the termination request is used to request the target database to stop executing the data query request; the prompt message includes indication information of the query timeout status of the data query request and reconstruction suggestion information for the data query request.

[0013] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps included in any of the foregoing method embodiments.

[0014] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps included in any of the foregoing method embodiments.

[0015] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps included in any of the foregoing method embodiments.

[0016] The aforementioned database request processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product, by preempting control before the gateway times out and sending a forced termination command to the server via the database driver interface, immediately terminate the query process being executed by the database, ensuring timely reclamation of database connection resources. In this application embodiment, before the gateway timeout threshold is reached, a prompt message containing a business status code and a list of reconstruction suggestions is returned to the terminal, transforming the timeout response from the technical symbol "504 error page" to easily understandable business guidance such as "query too heavy, suggest narrowing the time range," thus eliminating the operational blind spot for users facing error pages in related technologies. Furthermore, this application embodiment relies only on the basic programming interfaces of the application server and database driver, without introducing third-party microservice components, incurring no additional class loading overhead or configuration complexity, and can be embedded into legacy systems or lightweight services with zero intrusion, possessing high universality and portability. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is an application environment diagram of a database request processing method in one embodiment;

[0019] Figure 2 This is a flowchart illustrating a database request processing method in one embodiment;

[0020] Figure 3 This is a structural block diagram of a database request processing device in one embodiment;

[0021] Figure 4 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0023] Explanation of related terms:

[0024] Gateway: The system's traffic entry point (such as Nginx, API Gateway), responsible for request routing and load balancing, and usually has a mandatory network connection timeout threshold.

[0025] Preemptive Timeout: This refers to a timeout threshold set internally by the application server that is shorter than the timeout period for forced disconnection by the gateway, aiming to reclaim control in advance.

[0026] Resource isolation: Distribute different types of computing tasks (such as CPU-intensive and I / O-intensive tasks) into independent execution units (thread pools) to prevent a certain type of task from exhausting all system resources.

[0027] Zombie Task: Refers to an invalid task that continues to run silently in the background, consuming CPU and I / O resources, even after the client or gateway has disconnected.

[0028] Full-link interruption: This refers to an interruption signal that not only stops the execution of application-layer logic, but also forcibly terminates the query operation being executed by the remote database through driver-layer instructions.

[0029] Degradation Response: When the system cannot complete a scheduled operation, instead of directly throwing a system error, it returns a processed message with business guidance.

[0030] Before describing the embodiments of this application, the related technologies and their problems will be explained:

[0031] In current web application architectures, the general processing flow for handling time-consuming and complex database queries (such as report generation and large-scale data filtering) is as follows:

[0032] The client initiates an HTTP request, which is forwarded to the application server (Web Server) through the gateway.

[0033] The application server's main processing thread (Worker Thread) receives requests, obtains database connections, and sends SQL query commands to the database.

[0034] Gateway layers are typically configured with a fixed timeout period Tgateway (e.g., 60 seconds). If a database query takes longer than this time, the gateway will forcibly disconnect from the client and return a 504 Gateway Timeout error.

[0035] The aforementioned technologies have at least the following significant drawbacks in scenarios with high concurrency or a surge in data volume:

[0036] Resource leaks and "zombie task" accumulation: When the gateway disconnects, the application server and database do not receive a stop instruction. Query operations continue to run in the background until the database completes its task naturally. These invalid calculations consume valuable database connections and CPU resources, which can easily lead to connection pool exhaustion under high concurrency, triggering a service avalanche.

[0037] A hard barrier that lacks user experience: Users only receive meaningless 504 errors, unable to know whether it is a network problem or the query is too complicated, and cannot get effective suggestions such as "narrowing the query".

[0038] Framework dependency leads to bloat: Existing circuit breaker protection solutions (such as Spring Cloud Hystrix / Sentinel) often rely on large microservice frameworks, which introduce heavy class loading overhead and complex configuration maintenance costs, making them difficult to apply in lightweight services.

[0039] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0040] The database request processing method provided in this application embodiment can be applied to, for example, Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or located on the cloud or other network servers. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0041] In one exemplary embodiment, such as Figure 2 As shown, a database request processing method is provided, which is applied to... Figure 1 The example of server 104, such as an application server, will be used for illustration. The application server is the service node that carries business logic, such as Tomcat, Jetty, Undertow, or a Spring Boot embedded container. The application server is responsible for parsing terminal requests, executing business rules, interacting with the database, and generating responses. In this invention, the application server is the main body responsible for preemptive timeout control, resource isolation, end-to-end interruption, and degradation feedback. The target database is a persistent storage layer, such as MySQL, PostgreSQL, Oracle, or a cloud-native database. The database is responsible for executing SQL queries and returning result sets. Once the database query process starts, it will continue to execute until completion or crash without external intervention; this is the root cause of "zombie tasks."

[0042] The method includes the following steps: Step 202: Receive a data query request sent by the terminal through the gateway; the data query request is used to request a data query in the database.

[0043] In this context, the terminal refers to the client device or program operated by the user, including but not limited to browsers, mobile applications, desktop clients, mini-program front-ends, or other back-end services that call APIs. The terminal can initiate an HTTP request to the gateway, carrying business parameters for executing database queries. The gateway forwards the request to the corresponding application server instance according to routing rules. The gateway is an intermediate layer service located between the terminal and the application server cluster, providing a unified traffic entry point for the system. The core responsibilities of the gateway include request routing, load balancing, authentication, rate limiting and circuit breaking, and global timeout control. The gateway sets a mandatory timeout threshold (Tgateway) for each forwarded request. If the backend does not return a response within this threshold, the gateway actively disconnects the TCP connection with the terminal and returns a 504 error. There is no direct network connection between the application server and the terminal; all requests and responses must be forwarded through the gateway.

[0044] Data query requests can be RESTful API calls based on the HTTP / HTTPS protocol, or messages using gRPC or other RPC protocols. The request body or query parameters contain placeholder parameters for the target database identifier, the SQL statement to be executed, or a prepared statement.

[0045] Optionally, data query requests can specifically correspond to complex query scenarios that are time-consuming and resource-intensive, and can be triggered by at least one of the following scenarios:

[0046] Report generation: In enterprise-level SaaS systems, users request the generation of annual / quarterly sales reports, inventory turnover analysis reports, or financial summary reports. These queries typically involve multi-table joins, aggregation calculations (SUM, COUNT, GROUP BY), and sorting operations on tens to hundreds of millions of data points, with execution times reaching tens of seconds or even minutes.

[0047] Exporting large volumes of data: Users request to export all order records, operation logs, or business details. Although the database supports streaming returns, the server still needs to perform a full table scan and serialize the result set into formats such as Excel and CSV, resulting in an overall time consumption far exceeding the threshold of conventional interfaces.

[0048] Online analytics: In business intelligence (BI) dashboards or data dashboards, users generate queries in real time by dragging and dropping dimensions and metrics. Because query conditions are unpredictable and may lack suitable indexes, the database may perform a full table scan, leading to a sharp increase in response time.

[0049] Scheduled batch processing tasks: These are nighttime batch calculation tasks triggered by the scheduling system, such as billing and settlement, credit score updates, etc. Although these tasks do not involve real-time user interaction, they may slow down the database connection pools of other online services in a resource-contention environment. Therefore, the isolation and interruption mechanisms of this invention are also applicable.

[0050] Understandably, in the above scenario, if the traditional synchronous blocking model is used, the application server thread will be occupied for a long time, and a zombie task will be formed after the gateway times out. However, the embodiments of this application realize the orderly release of resources and the smooth degradation of user experience by identifying such requests and implementing pre-emptive timeouts and full-link interruptions in subsequent steps.

[0051] Specifically, the URL path of a data query request has a specific prefix (such as / api / reports / or / api / analytics / ) or carries a specific request header (such as X-Query-Type: Complex) for subsequent request type identification. After receiving the request, the application server obtains the request identifier (Request ID) it carries in order to perform end-to-end tracing.

[0052] Step 204: Send the data query request to the corresponding target database, and start listening to the response of the target database to the data query request for a continuous target duration; wherein, the target duration is less than the timeout duration threshold of the gateway; the timeout duration threshold is used to characterize the maximum waiting time of the gateway before disconnecting the connection with the terminal when no response result of the data query request is received.

[0053] After obtaining a database connection, the application server sends data query requests (such as SQL statements) to the target database through this connection. The target database is a persistent storage layer, such as MySQL, PostgreSQL, Oracle, or a cloud-native database. It's important to note that the database is responsible for executing the SQL query and returning the result set. Once the database query process starts, it will continue to execute until completion or a crash without external intervention; this is the root cause of "zombie tasks." Simultaneously, the application server starts a timed monitor with a countdown duration, the target duration Tapp. The target duration Tapp is a positive integer less than the gateway timeout threshold Tgateway. For example, if the gateway's proxy_read_timeout is configured to be 60 seconds, then Tapp can be configured to be 55 seconds. The specific value of Tapp can be a statically configured fixed value or a value dynamically calculated based on Tgateway.

[0054] Considering that if the Tgateway is reached, the gateway will immediately disconnect from the database and stop waiting for the database's return result. At this point, neither the application server nor the database receives any stop signal, resulting in a double waste of resources: the application server thread waits idly, and the database query runs in vain. Therefore, in this embodiment, a shorter Tapp is set before the Tgateway is reached, shifting the point at which control is reclaimed from the gateway to the application server. When the Tapp times out, the application server remains in a normal connection state with the gateway, possessing full context permissions to send a termination command to the database and can write back a response to the gateway normally.

[0055] The listening mechanism refers to the maximum duration for which the application server waits for the database to return query results or error information, starting from the moment the query request is sent to the database. The listening mechanism can be implemented in various ways, such as asynchronous callbacks, Future.get(timeout), CompletableFuture.orTimeout, or a dedicated timed task thread pool.

[0056] Specifically, the application server sets the query timeout using the JDBC Statement.setQueryTimeout() method. It should be noted that the difference between the Tapp timeout set in this embodiment and the native JDBC timeout is that the value of Tapp is not arbitrary, but determined based on the gateway's timeout threshold; furthermore, the processing logic after a Tapp timeout does not simply throw an exception, but triggers a full-link interruption and degradation feedback process in subsequent steps.

[0057] Step 206: If no query result is received from the target database for the data query request within the target time period, a termination request is sent to the target database and a prompt message is returned to the terminal; wherein, the termination request is used to request the target database to stop executing the data query request; the prompt message includes an indication of the query timeout status of the data query request and a reconstruction suggestion for the data query request.

[0058] If the timed monitor does not capture a result set or completion signal from the database within the Tapp duration (i.e., the query is still executing), it determines that the query cannot be completed before the gateway times out. At this point, the application server performs the following two parallel actions:

[0059] The first action is to send a termination request to the database. The application server sends a forced termination command to the database server through a dedicated programming interface provided by the database driver layer. This command does not depend on the interruption status of the application layer thread but communicates directly with the database server's query execution engine. Specifically, after catching a timeout exception, the application server calls the `Statement.cancel()` method holding the database statement object. The JDBC driver implementation layer translates this method call into a network packet matching the database protocol (e.g., the `COM_QUERY` or `KILL` command in the MySQL protocol) and sends it to the database server. Upon receiving this command, the database server immediately terminates the currently executing query thread on the corresponding connection, rolls back the lock resources occupied by the current transaction, and releases the memory cursor and temporary tablespace associated with the query. This ensures that the database's CPU and I / O resources are released immediately, preventing the database from continuing to execute invalid SQL operations and consuming CPU, memory, lock resources, and connection pools. This avoids the situation where dozens of zombie tasks can exhaust the database connection pool and cause a service avalanche in high-concurrency scenarios.

[0060] Considering that simply terminating the database query without returning a prompt would result in the terminal receiving a 504 error page after waiting for the Tgateway to time out, users would be unable to distinguish whether the issue stemmed from a network failure, system crash, or excessive query complexity, leading to confusion, duplicate submissions, and even customer complaints. Therefore, a second action can be taken: returning a prompt message to the terminal. Instead of waiting for confirmation of the database termination operation (which typically takes milliseconds), the application server constructs a structured HTTP response and returns it to the terminal via the gateway. This prompt message is a business-level response, and its data structure can be represented in JSON format, containing at least the following fields: status or code: a business status code, such as "QUERY_TIMEOUT" or 408001, used by the terminal or front-end program to identify timeout scenarios. message: a user-friendly, readable prompt text, such as "Your query request took too long to execute and has been automatically terminated." suggestions: a list of refactoring suggestions, which can be a list of strings and may include information such as: "Please narrow down the query time range, for example, select the last 30 days," "Please add more filtering conditions, such as specifying a specific business line or region," and "The current report data volume is large; it is recommended to run during off-peak hours or use the scheduled export function," etc.

[0061] It should be noted that the physical communication path for "returning prompt information to the terminal" in this embodiment is: application server to gateway to terminal. The application server sends an HTTP response packet containing the prompt information to the gateway, and the gateway forwards the response to the terminal according to its connection status. Since this embodiment constructs a response immediately when Tapp times out, the TCP connection between the gateway and the terminal is still in a normal state and has not yet reached Tgateway. Therefore, the gateway will not interrupt this connection, but will complete the response forwarding in a normal proxy manner.

[0062] By setting the numerical relationship between the target duration and the gateway's timeout threshold, in this embodiment of the application, the prompt message is returned before the gateway's timeout threshold is reached. Since Tapp < ​​Tgateway, and the termination request and response are constructed within tens of milliseconds, the terminal can receive a complete and business-meaning JSON response before the gateway actively disconnects the connection (e.g., at the 58th second), rather than receiving an error page at the 60th second (i.e., when the gateway's timeout threshold has been reached).

[0063] This differs from related technologies that rely solely on gateway timeouts, resulting in no backend intervention and creating zombie tasks. This embodiment proactively intervenes before gateway timeouts, achieving both resource release and business response. Unlike JDBC timeouts, which only throw application-layer exceptions and do not guarantee the database query process will be terminated (in many database driver implementations, timeouts only stop the client from waiting while the server continues running), this embodiment sends a forced termination command to the database server through a driver-layer interface (such as `Statement.cancel()`), ensuring the database query process is immediately stopped. Circuit breaker frameworks focus on call chain protection (such as fail-fast and thread pool isolation), but after a timeout, they neither send a termination command to the database nor return structured business information to the user, typically throwing a `TimeoutException` or returning a static fallback value. This embodiment, based on the circuit breaker concept, extends downwards to the database driver layer and upwards to the user experience layer, building end-to-end governance capabilities from the database to the client.

[0064] In summary, this application embodiment ensures that timed-out queries do not idle on the database side by actively terminating at the driver layer, thus releasing valuable database connections and computing resources. Furthermore, by transforming the technical fault of "network timeout" into a business prompt of "query overload" and providing specific and feasible operational suggestions, it avoids users from submitting invalid duplicates. It also ensures that responses are returned normally within the gateway timeout threshold, preventing the gateway from accumulating a large number of half-connections or triggering circuit breakers due to passive timeouts, thereby maintaining the health of the entire link.

[0065] In some embodiments, before sending the data query request to the corresponding target database and starting continuous monitoring of the target database's response to the data query request for a target duration, the method further includes:

[0066] The data query request is analyzed to determine whether it is a long-running query request.

[0067] If the data query request is a long-running query request, the data query request is encapsulated into an asynchronous task and submitted to the asynchronous task scheduler;

[0068] The asynchronous task scheduler sends the data query request to the target database.

[0069] The request type analysis is used to identify query tasks with potential long processing times from a large number of regular requests that are suitable for entering the asynchronous isolation chamber, thereby avoiding the indiscriminate application of the asynchronous and isolation mechanism of this invention to all requests, which would cause unnecessary performance overhead.

[0070] Specifically, long-running query requests can be database query operations whose expected execution time is significantly longer than that of ordinary online transaction processing requests. In this embodiment, long-running query requests do not have a strict absolute time definition, but are defined relative to the gateway timeout threshold Tgateway: if the expected execution time of a query may be close to or exceed Tgateway, or its historical P95 / P99 response time is significantly higher than the average business response time, then it is classified as a long-running query.

[0071] Determining whether a data query request is a long-running query can be achieved through any of the following methods or a combination thereof: Method 1: Identification based on Uniform Resource Locator (URL) path. The application server is configured with a set of predefined URL pattern matching rules. When the URL path of a received request matches a specific prefix, suffix, or wildcard pattern, the request is determined to be a long-running query. Method 2: Identification based on request header tags. The client or gateway can add custom fields to the HTTP request header in the protocol negotiated with the application server to explicitly declare the expected execution characteristics of the request. Method 3: Identification based on request parameter characteristics. The application server parses the request body or query parameters and dynamically evaluates the complexity of the query based on characteristics such as the number of parameters, the range of values, and the number of related tables. For example, a report query interface accepts startDate and endDate as time range parameters. If the span between the two dates exceeds a preset threshold (e.g., 90 days), the application server determines that the query may involve an excessively large data scan range and identifies it as a long-running query request. Optionally, the query interface accepts a list of departmentIds parameters. If the number of elements in the list exceeds 10, the application server determines that the query needs to aggregate data from multiple business units and identifies it as a long-running query request.

[0072] If the current request is identified as a query with long execution time, the application server's main processing thread will not directly execute the database call logic for that request, but will instead perform a context switch operation. Encapsulating this as an asynchronous task involves the main thread packaging the current request's context information, including request parameters, user identity, tracing identifiers, and target database connection information, into a discrete, independently schedulable unit of work.

[0073] The asynchronous task may contain at least the following information: Request payload: The SQL statement to be sent to the database or its pre-compiled placeholder parameters. Callback address: The path for notifying the result after the asynchronous task is completed. Timeout context: The target duration Tapp corresponding to this request, used for subsequent pre-emptive monitoring. Request identifier: The Request ID used for end-to-end tracing.

[0074] The main thread pushes the encapsulated asynchronous task object to a globally unique scheduling component specifically designed for receiving long-running query tasks. This submission operation is non-blocking; that is, the main thread is only responsible for "submitting" the task and does not wait for it to complete. Specifically, the asynchronous task scheduler provides the `submitAsyncQuery(Task task)` method. After the main thread calls this method, the task is placed in the scheduler's internal queue, and the method immediately returns a `Future` or `CompletableFuture` object. The main thread can use this object to obtain the execution result or cancel the task in subsequent stages.

[0075] In this embodiment, after submitting the asynchronous task, the main thread immediately returns from the current request processing flow and no longer holds any resources related to the request. In a web container model, this means that the Servlet thread or Controller thread handling the HTTP request is immediately returned to the container's main business thread pool, ready to be used for the next pending request. The asynchronous task scheduler maintains one or more query execution thread pools, which are physically isolated from the main business thread pool handling regular requests. The scheduler retrieves pending asynchronous tasks from an internal queue and dispatches them to idle worker threads in the query execution thread pool. After being awakened, the worker thread executes the same database operation sequence as in the synchronous mode: parsing the target database identifier and SQL statement / parameters from the asynchronous task object; obtaining a database connection from the database connection pool; sending a query command to the target database through the connection; and waiting for the database to return the query results.

[0076] It's important to note that the waiting here refers to blocking at the worker thread level, not at the web container thread level. Because the worker thread pool is a dedicated pool designed specifically for long-running queries, its thread count is strictly controlled (e.g., a small number of 5-10 threads), and it is completely isolated from the main business thread pool. Therefore, the blocking of these worker threads will not affect the web container's ability to receive and process other regular requests.

[0077] The execution entity responsible for "sending the data query request to the corresponding target database" and its accompanying "starting continuous listening for the target duration" is the worker thread dispatched by the scheduler here. That is: the main thread is responsible for identification and submission; the scheduler is responsible for dispatching and execution; and the worker thread is responsible for the actual sending and listening.

[0078] Through the aforementioned scheduler dispatch mechanism, this embodiment of the application achieves spatial isolation between the request receiving thread and the query execution thread. The main business thread pool is responsible for "receiving orders," while the dedicated worker thread pool is responsible for "cooking." Even if the "cooking" process is completely blocked due to slow database queries, only a small number of threads in the dedicated thread pool are occupied. The main business thread pool can still respond to requests from core lightweight interfaces such as login, order placement, and product list queries in milliseconds, thereby achieving compartmentalized isolation and effectively preventing the avalanche effect of slow queries dragging down the entire service.

[0079] In some embodiments, the asynchronous task scheduler maintains a query execution thread pool, which is physically isolated from the main business thread pool that processes other types of requests from the terminal, excluding long-running query requests; the asynchronous task scheduler is a singleton object initialized on demand; the waiting queue of the query execution thread pool includes a bounded queue.

[0080] Sending the data query request to the target database via the asynchronous task scheduler includes:

[0081] The asynchronous task is executed through the query execution thread pool to send the data query request to the target database.

[0082] The query execution thread pool is a thread resource pool within the asynchronous task scheduler responsible for executing database query operations. This thread pool is physically isolated from the main business thread pool used by the web container (such as Tomcat, Jetty, or Undertow) to handle HTTP requests. Physical isolation means that the two thread pools belong to different thread groups in the Java Virtual Machine (JVM) memory, and their thread instances, blocking queues, rejection policies, and lifecycle management are all independent, with no sharing or overlap. A thread in the main business thread pool cannot directly execute tasks in the query execution thread pool, and vice versa. The allocation, release, and exhaustion of thread resources are strictly limited to their respective pool domains.

[0083] For example, the main business thread pool could be the default executor of the Spring Boot embedded Tomcat, with its thread count configured as `server.tomcat.threads.max=200`, used to handle all HTTP requests entering the web container. Correspondingly, the query execution thread pool could be a separate thread pool manually created by the asynchronous task scheduler using `java.util.concurrent.ThreadPoolExecutor`, with its core thread count configured as `corePoolSize=5` and its maximum thread count configured as `maximumPoolSize=10`, dedicated to executing the aforementioned long-running asynchronous query tasks.

[0084] In this embodiment, by physically isolating the query execution thread pool from the main business thread pool, fault propagation is prevented. When complex report queries are completely stalled due to database jitter or deadlock, only 5-10 worker threads in the query execution thread pool are affected, and the blocking state of these threads will not spread to the 200 threads in the Tomcat main thread pool. Core lightweight interfaces such as user login, product browsing, order placement and payment are still responded to by the main business thread pool in milliseconds, and the overall service availability is maintained.

[0085] On-demand initialization means that the asynchronous task scheduler and its internally maintained query execution thread pool are not created immediately when the application server starts, but are instantiated only when a long-running query request is received for the first time. A singleton object means that the asynchronous task scheduler has one and only one instance throughout the entire application server lifecycle. All long-running query tasks are submitted to the same scheduler instance, which uniformly manages the lifecycle of the query execution thread pool, the task queue, and the dispatch logic.

[0086] Specifically, the asynchronous task scheduler is implemented using the Initialization-on-demand holder idiom. This pattern leverages the Java class loading mechanism to hold the scheduler instance in an inner static class. The inner static class is only loaded and instantiated when the method to obtain the instance is explicitly called externally.

[0087] When the application server runs for a long time and does not receive any long-running query requests (e.g., in a pure OLTP scenario), the scheduler object and its thread pool will never be created, thus not consuming any system resources. In this embodiment, by using a singleton scheduler initialized on demand, resource consumption is precisely matched to business load. For microservice instances that never use complex query functions, they will not consume any additional thread resources due to the introduction of this invention. For large-scale distributed deployment scenarios, massive service instances do not need to reserve thread pools for complex queries that "may never be executed," thereby significantly reducing the overall idle resource overhead of the cluster.

[0088] A waiting queue is a blocking queue in the query execution thread pool used to store asynchronous tasks that have been submitted but have not yet been assigned a worker thread for execution. When the rate of task submissions exceeds the thread pool's processing capacity, newly arriving tasks are queued. A bounded queue means that the queue has a fixed, explicitly configured maximum capacity limit. When the number of queued tasks reaches this capacity limit, the thread pool will no longer accept new tasks and will trigger a preset rejection policy.

[0089] Specifically, the query execution thread pool uses a LinkedBlockingQueue and explicitly specifies its capacity. The difference between this and an unbounded queue is that an unbounded queue (e.g., `new LinkedBlockingQueue<>()`) has a capacity of `Integer.MAX_VALUE`, theoretically allowing tasks to accumulate indefinitely. In scenarios where the downstream database is consistently slow or experiencing failures, task backlog will consume memory indefinitely, eventually leading to an application server heap memory overflow (OOM) and triggering more severe cascading failures. When the bounded queue is full and the number of worker threads in the thread pool has reached the maximum number of threads (`maximumPoolSize`), the thread pool rejects newly submitted tasks. This embodiment uses an `AbortPolicy`, which directly throws a `RejectedExecutionException`, which can be caught by the upper-level caller and converted into a fast failure response on the client side.

[0090] By configuring a bounded queue for the query execution thread pool, this embodiment of the application achieves memory safety and backpressure protection. The bounded queue acts as a pressure buffer: when database performance is normal, the queue can be consumed after a brief backlog; when database performance is severely degraded, the queue is quickly filled and a fast failure is triggered, preventing memory leaks caused by infinite task backlog. This mechanism, together with the physically isolated thread pool, constitutes a double layer of protection—bulk isolation to prevent thread resource exhaustion, and the bounded queue to prevent memory resource exhaustion.

[0091] By anchoring the actual execution of asynchronous tasks to a query execution thread pool, this embodiment of the application completes a fully isolated link from request access to database query. The main business thread pool is only responsible for "accepting orders" and "returning results," and its processing speed is always maintained at the microsecond level. Database interaction operations that may pose a blocking risk are diverted to a dedicated, capacity-limited, bounded queue-protected isolated thread pool. This ensures that the basic request processing capabilities of the web container remain intact in the event of a database failure.

[0092] In some embodiments, sending the data query request to the target database and starting continuous monitoring of the target database's response to the data query request for a target duration includes:

[0093] The target duration is determined based on the timeout duration threshold and the preset buffer duration.

[0094] The timeout duration threshold is the mandatory timeout period Tgateway configured at the gateway layer. This threshold is a predetermined configuration at the gateway layer, and its value is set by the system architect or operations personnel based on business tolerance, service level agreements, and infrastructure stability. In this embodiment, the application server does not need to dynamically detect or query the gateway's Tgateway value in real time; instead, it obtains this baseline parameter through static configuration or deployment-time injection.

[0095] The preset buffer duration is denoted as Δt. When setting Δt, at least one of the following three dimensions can be considered:

[0096] The first dimension: Response construction and transmission time. From the timeout trigger on Tapp to the application server completing the termination request, serializing the notification message, writing the HTTP response back to the gateway, and then the gateway forwarding the response to the terminal, this complete chain takes a certain amount of time. Under normal load, this time is typically 50-200 milliseconds. Δt needs to be greater than this chain time to ensure that the notification message is indeed delivered to the terminal before Tgateway arrives.

[0097] The second dimension: Network jitter tolerance. There may be instantaneous network latency fluctuations between the terminal and the gateway, and between the gateway and the application server. If Δt is too small (e.g., 0.5 seconds), even slight TCP retransmissions or operating system scheduling delays may cause the response to arrive at the gateway only after the Tgateway times out. By this time, the gateway has already disconnected, the response is discarded, and the user still receives a 504 error. Therefore, Δt needs to reserve sufficient network jitter buffer.

[0098] The third dimension: the hierarchical progression principle of multi-level timeout configuration. In distributed systems, timeout configuration should follow the golden rule of downstream being shorter than upstream. The application server's timeout setting for the database (Tapp) needs to be shorter than the gateway's timeout setting for the application server (Tgateway), and the gateway's timeout needs to be shorter than the client's timeout setting for the gateway. Δt is the specific numerical manifestation of this hierarchical progression principle.

[0099] The target duration Tapp is the final time parameter used for pre-emptive timeout monitoring. Its value is determined by arithmetic operations between Tgateway and Δt, and can be expressed as follows:

[0100] Tapp = Tgateway – Δt;

[0101] Where Tgateway > Δt > 0, meaning the target duration is strictly less than the gateway timeout threshold, and the buffer duration is positive. Understandably, when Tapp = Tgateway: both the application server and the gateway trigger timeouts simultaneously, creating a race condition. If the gateway is slightly faster, the connection is already broken, and the application server's termination request and notification messages cannot be delivered, resulting in a 504 error for the user and a zombie task in the database. When Tapp > Tgateway: the gateway timeout triggers first, the connection is broken, and the application server has not yet detected the timeout (still waiting). When subsequent Tapp arrives, there is no connection context; although the termination request can be sent to the database, the user will not receive any notification messages.

[0102] For example, the gateway timeout Tgateway is configured to be 60 seconds. Based on a rule of thumb, the operations and maintenance personnel set a buffer duration Δt = 5 seconds, then Tapp = 55 seconds. This 5-second buffer is broken down as follows: 0.2 seconds for application server response construction and termination commands, 0.3 seconds for gateway internal processing and forwarding, 0.5 seconds for network round-trip RTT, and the remaining 4 seconds as a safety margin to handle sudden loads or garbage collection pauses.

[0103] By introducing a configurable buffer duration Δt, this embodiment of the application achieves an explicit trade-off between the degree of intervention aggression and the risk of misjudgment. A larger Δt provides a more robust user experience guarantee (the response will almost certainly arrive before the gateway times out), but it narrows the executable time window for database queries; a smaller Δt maximizes the chance of database queries completing, but it places higher demands on system response speed and network quality. Operations personnel can adjust the "pre-emption intensity" of this invention using a knob based on business characteristics and the current state of the infrastructure.

[0104] This application does not limit the specific implementation of "determining the target duration" in its embodiments; both static pre-setting and dynamic calculation are supported. For example, operations personnel can directly configure the absolute value of Tapp, such as app.query-timeout=55. This method is simple and intuitive, suitable for environments where the gateway timeout threshold remains stable over a long period. The application server does not need to execute any calculation logic; it can directly read the configuration upon startup. Optionally, the application server reads Tgateway and Δt upon startup, performs the calculation Tapp = Tgateway - Δt, and uses the result as the global timeout parameter. The advantage of this method is that when the operations team uniformly adjusts the gateway timeout policy (e.g., increasing it from 60 seconds to 120 seconds), there is no need to simultaneously modify the application server's timeout configuration. After the application server restarts, it will automatically calculate the new Tapp (115 seconds) based on the new Tgateway. This reduces the configuration management complexity of large-scale clusters.

[0105] In some embodiments, the step of sending a termination request to the target database and returning a prompt message to the terminal if no query result is received from the target database for the data query request within the target time period further includes:

[0106] Interrupt the asynchronous task of sending the data query request to the target database and release the thread executing the asynchronous task in the query execution thread pool;

[0107] Sending a termination request to the target database includes:

[0108] By calling the query cancellation interface provided by the driver layer of the target database, an instruction is sent to the server of the target database to terminate the query process corresponding to the data query request.

[0109] Interrupted execution refers to the application server actively terminating the ongoing asynchronous task processing logic after a preemptive timeout is triggered. This can be achieved by using a task cancellation mechanism provided by a programming language or framework to send an explicit stop signal to the executing thread. In this embodiment, when an asynchronous task is submitted to the scheduler, it returns a Future or CompletableFuture object. This object holds a reference to the currently executing task and provides a standard task cancellation interface. When no database query result is received within the target duration Tapp, the timeout monitoring logic holds the Future object and calls its cancel(true) method. The cancel(true) method is used to set the task's interrupt flag. For threads blocked on interruptible operations (such as Thread.sleep, Object.wait, BlockingQueue.take, and some database driver APIs), setting this flag will cause it to throw an InterruptedException, thus exiting the blocked state early. The cancel(true) method is also used to mark the task status as "cancelled". The asynchronous task scheduler checks whether the task has been cancelled when dispatching tasks. If a task is canceled while waiting in the queue for execution, the scheduler will discard the task directly and will not dispatch it to the worker thread, thus saving thread resources.

[0110] It's important to note that relying solely on application-layer thread interruption is insufficient to guarantee the termination of the database query process. Thread interruption only affects the application server locally; the database server is completely unaware of the interruption event, and its query engine will continue execution until completion. Releasing the thread executing the asynchronous task from the query execution thread pool means that the interrupted worker thread performs the following resource cleanup actions before exiting task execution: The worker thread holds a database connection object borrowed from the connection pool. Regardless of whether the query is completed, the connection needs to be closed or returned to the connection pool to avoid connection leaks. Context information such as request tracking identifiers and user identities stored in ThreadLocal is cleared to prevent this data from polluting subsequently reused threads. Finally, after completing the current task, the worker thread returns to an idle state, waiting to retrieve the next task from the bounded queue.

[0111] By interrupting asynchronous tasks and releasing worker threads, this embodiment of the application achieves rapid reclamation of application server thread resources. The occupied query execution thread pool threads are restored to an idle state within milliseconds and can be immediately assigned to the next pending asynchronous task. This prevents the dedicated thread pool from being exhausted due to a large backlog of timed-out tasks, forming a dual protection of front-end buffering and back-end rapid reclamation with the bounded queue mechanism.

[0112] The database driver layer refers to the protocol adaptation layer that enables communication between the application and the database, such as JDBC drivers, ODBC drivers, and R2DBC drivers. This layer encapsulates the network protocol details for interacting with the database server, converting standard API calls from the application layer into database-specific command messages. The query cancellation interface is a programming interface explicitly exposed by the database driver layer for actively terminating an ongoing database query operation. For example, in the MySQL Connector / J driver, the implementation mechanism of the cancel() method may include: the driver extracting the thread ID (CONNECTION_ID() in MySQL) corresponding to the query from the held Statement object. Each MySQL client connection corresponds to a foreground thread on the server, and this thread ID uniquely identifies the currently executing query session. The driver constructs a special KILL QUERY command, in the format: KILL CONNECTION_ID or KILL QUERY ID. This command is wrapped as a new network packet and sent to the MySQL server through an independent, non-interrupted connection channel. After receiving the KILL QUERY command, the MySQL server locates the corresponding query thread and performs the following operations: immediately stops the SQL statement being executed by the thread; rolls back the row locks and table locks held by the current transaction; releases resources such as temporary tables and file sorting buffers associated with the query; and returns a termination confirmation message to the client driver.

[0113] It should be noted that the technical concept of this application embodiment is not limited to relational databases. For NoSQL databases or cloud-native databases that support query termination commands, corresponding driver-layer cancellation interfaces also exist. For example, the MongoDB Java driver provides `MongoCursor.close()` or `OperationContext.markKilled()`; the ElasticsearchRest High Level Client supports a cancel task API. This application embodiment sends an explicit termination command to the database server through the driver-layer protocol, and is not limited to the JDBC specification or a specific database brand. By sending a forced termination command to the database server through the driver-layer query cancellation interface, this application embodiment achieves the immediate release of database resources.

[0114] Unlike related technologies that only release application server threads while the database query process remains idle, continuously consuming CPU cycles, memory buffers, row locks, and connection slots, this application extends resource release from the application layer to the database layer, effectively eliminating the erosion of the database system by "zombie queries." Application-layer interruption wakes up blocked worker threads from query waiting, releases local memory context, returns database connections, and allows limited dedicated thread pool resources to be reused. Driver-layer termination sends a forced termination command to the server via the database's native protocol, stopping the remote query process and releasing cluster-shared resources such as locks, cursors, and temporary tables.

[0115] In some embodiments, the step of sending a termination request to the target database and returning a prompt message to the terminal if no query result is received from the target database for the data query request within the target time period includes:

[0116] The abnormal information indicating that the query result was not received within the target time period is mapped to structured data containing business status codes and a list of operation suggestions to obtain the prompt information.

[0117] In this context, exception information refers to a runtime exception object generated internally by the application server when the target duration Tapp listener times out. This exception represents the technical fact that "this query could not be completed before the gateway timeout." In the Java implementation, this exception can be TimeoutException, InterruptedException, or a custom PreemptiveTimeoutException.

[0118] It's important to note that the exception information here is not the final content presented to the terminal, but rather a technical signal for internal system use. This is because directly returning the raw exception stack trace or SQLException error code to the client would be meaningless for business operations, as end users lack the technical background to interpret java.sql.SQLTimeoutException or MySQL Error Code 1317. Furthermore, technical exceptions only describe "what error occurred," failing to convey the business intent of "what the user should do next."

[0119] Therefore, in this embodiment, the application server can have a built-in exception conversion unit. This unit can be a standalone component (such as QueryTimeoutExceptionResolver), an AOP-based interceptor (such as @ControllerAdvice), or a post-filter embedded in the API gateway layer. When the end-to-end interruption process is triggered, the timeout monitoring logic throws a wrapped PreemptiveTimeoutException. This exception propagates upwards along the asynchronous callback chain and is captured by the exception conversion unit.

[0120] The exception conversion unit checks the exception type. If it is a PreemptiveTimeoutException or its parent class TimeoutException, it is determined to be a "preemptive timeout" scenario, and the structured mapping process begins. The exception conversion unit extracts at least one of the following information from the current request context: Request ID (for log association and tracing); Target database identifier (for differentiating timeout frequencies from different data sources); User identity or tenant identifier (for personalized recommendations); and Original SQL summary (not complete SQL, to avoid leaking business data) for subsequent slow query optimization analysis. The exception conversion unit calls a preset mapping strategy to combine the technical exception with the context information to generate a structured business response object.

[0121] The business status code refers to a custom code used to identify a specific business status in an application layer protocol (such as HTTP). Unlike standard HTTP status codes (such as 200, 400, and 504), business status codes do not indicate success or failure at the transport layer, but rather represent specific semantics at the business processing layer. Specifically, different status codes are used for query timeouts in different business domains. Terminals or front-end programs can present different interactive prompts based on the differences in status codes. For example, a timeout in the report module can directly redirect to the "Schedule Generation" interface, while a timeout in the export module can automatically retry the query with a narrowed time range. Optionally, the business status code adopts a segmented encoding rule; the first three digits (408) follow the HTTP semantics of "client timeout," and the last three digits are assigned by each business line. When adding a new business module, there is no need to modify the core exception conversion logic; only the new status code mapping rule needs to be registered.

[0122] The action suggestion list refers to the actionable follow-up instructions for end users associated with this timeout query. This list is the final manifestation of the core value of this invention: "transforming technical faults into business interactions." Specifically, the design of the action suggestion list can follow these principles: Suggestions should be behavioral instructions pointing to specific operations. For example, "Please narrow down the time range of your query" is better than "The system is busy, please try again later." Suggestions should be strongly relevant to the context of the current request. The returned action suggestions should be differentiated for requests from different business domains, with different parameter characteristics, and with different user permissions. Furthermore, when multiple suggestions exist, they should be sorted from highest to lowest according to expected effectiveness, with the suggestion most likely to resolve the timeout issue placed first.

[0123] For example, in scenarios where queries time out due to an excessively large time range, if the original request carries startDate and endDate parameters and the time span exceeds 90 days, the exception conversion unit automatically generates the following suggestion list:

[0124] Json;

[0125] “suggestions”: [;

[0126] "Shorten the query time range to within 30 days"

[0127] "Query by month segment and merge the results in the client."

[0128] "Use the 'Scheduled Export' function to run during off-peak hours"; ];

[0130] For scenarios where queries time out due to a lack of filtering conditions, if the original request does not include any filtering conditions such as business line, department, or product category, and involves multiple table joins, the following suggested list can be generated:

[0131] json;

[0132] “suggestions”: [;

[0133] Add a 'business line' or 'department' filter.

[0134] "Specify a specific product category or supplier"

[0135] "Exclude archived historical data"; ];

[0137] Optionally, for high-frequency timeout business lines, if the exception conversion unit identifies through the request context that the request belongs to a specific business line (such as "Annual Business Analysis Report"), and that business line has triggered multiple timeouts in the past 24 hours, the following suggestion list can be generated:

[0138] json;

[0139] “suggestions”: [;

[0140] "The report contains tens of millions of data points; we recommend using the 'pre-calculated results' version."

[0141] "Please contact the data analytics team to create a materialized view for you."

[0142] "Avoid operating during the peak hours of 10:00-11:00 AM"; ];

[0144] By providing a dynamically configurable list of operational suggestions, this application's embodiment achieves a closed-loop business strategy for handling faults. In related technologies, users receiving a 504 error are trapped in a vicious cycle of "guessing-retrying-timeout again." This step, by providing precise and actionable operational guidance, directs users to submit the correct parameters in one go, reducing the probability of timeouts from the source. Simultaneously, the suggestion rule engine enables non-technical personnel (product, operations) to participate in system stability governance, transforming timeout optimization from "R&D scheduling driven" to "business strategy driven."

[0145] Structured data refers to the unified encapsulation of heterogeneous data such as exception information, business status codes, and operation suggestion lists into data transmission objects with clearly defined fields and strong type constraints. The data structure of structured data can have at least one of the following characteristics: field naming uses business-oriented language, allowing front-end developers to understand the purpose of each field without consulting documentation; adding fields does not affect the parsing logic of the already deployed front-end; it supports incremental iteration; and it supports observability embedding, such as aligning the requestId field with the tracking ID of backend logs and database slow query logs, so that when users report timeout issues, operations personnel can quickly locate the complete request chain based on this ID.

[0146] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0147] Based on the same inventive concept, this application also provides a database request processing apparatus for implementing the database request processing method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more database request processing apparatus embodiments provided below can be found in the limitations of the database request processing method described above, and will not be repeated here.

[0148] In one exemplary embodiment, such as Figure 3 As shown, a database request processing apparatus 300 is provided, comprising:

[0149] The receiving module 302 is used to receive a data query request sent by the terminal through the gateway; the data query request is used to request a data query in the database.

[0150] The monitoring module 304 is used to send the data query request to the corresponding target database and start monitoring the response of the target database to the data query request for a continuous target duration; wherein, the target duration is less than the timeout duration threshold of the gateway; the timeout duration threshold is used to characterize the maximum waiting time of the gateway before disconnecting the connection with the terminal when no response result of the data query request is received;

[0151] The sending module 306 is configured to send a termination request to the target database and return a prompt message to the terminal if no query result is received from the target database for the data query request within the target time period; wherein, the termination request is used to request the target database to stop executing the data query request; the prompt message includes indication information of the query timeout status of the data query request and reconstruction suggestion information for the data query request.

[0152] In some embodiments, the monitoring module 304 is further configured to, before sending the data query request to the corresponding target database and starting continuous monitoring of the target database's response to the data query request for a target duration, further include:

[0153] The data query request is analyzed to determine whether it is a long-running query request.

[0154] If the data query request is a long-running query request, the data query request is encapsulated into an asynchronous task and submitted to the asynchronous task scheduler;

[0155] The asynchronous task scheduler sends the data query request to the target database.

[0156] In some embodiments, the asynchronous task scheduler maintains a query execution thread pool, which is physically isolated from the main business thread pool that handles other types of requests from the terminal, excluding the long-running query request; the asynchronous task scheduler is a singleton object initialized on demand; the waiting queue of the query execution thread pool includes a bounded queue; the listening module 304 is further configured to: execute the asynchronous task through the query execution thread pool to send the data query request to the target database.

[0157] In some embodiments, the monitoring module 304 is further configured to: determine the target duration based on a timeout duration threshold and a preset buffer duration.

[0158] In some embodiments, the sending module 306 is further configured to:

[0159] Interrupt the asynchronous task of sending the data query request to the target database and release the thread executing the asynchronous task in the query execution thread pool;

[0160] Sending a termination request to the target database includes:

[0161] By calling the query cancellation interface provided by the driver layer of the target database, an instruction is sent to the server of the target database to terminate the query process corresponding to the data query request.

[0162] In some embodiments, the sending module 306 is further configured to:

[0163] The abnormal information indicating that the query result was not received within the target time period is mapped to structured data containing business status codes and a list of operation suggestions to obtain the prompt information.

[0164] Each module in the aforementioned database request processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can invoke and execute the operations corresponding to each module.

[0165] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 4As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When executed by the processor, the computer program implements a database request processing method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0166] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0167] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps included in any of the foregoing method embodiments.

[0168] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps included in any of the foregoing method embodiments.

[0169] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps included in any of the foregoing method embodiments.

[0170] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0171] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0172] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0173] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A database request processing method, characterized in that, The method includes: The receiving terminal sends a data query request through the gateway; the data query request is used to request a data query in the database. The data query request is sent to the corresponding target database, and the response of the target database to the data query request is monitored for a continuous target duration; wherein, the target duration is less than the timeout duration threshold of the gateway; the timeout duration threshold is used to characterize the maximum waiting time of the gateway before disconnecting the connection with the terminal if no response result of the data query request is received. If no query result is received from the target database in response to the data query request within the target time period, a termination request is sent to the target database and a prompt message is returned to the terminal; wherein, the termination request is used to request the target database to stop executing the data query request; the prompt message includes an indication of the query timeout status of the data query request and a reconstruction suggestion for the data query request.

2. The method according to claim 1, characterized in that, Before sending the data query request to the corresponding target database and starting continuous monitoring of the target database's response to the data query request for a target duration, the method further includes: The data query request is analyzed to determine whether it is a long-running query request. If the data query request is a long-running query request, the data query request is encapsulated into an asynchronous task and submitted to the asynchronous task scheduler; The asynchronous task scheduler sends the data query request to the target database.

3. The method according to claim 2, characterized in that, The asynchronous task scheduler maintains a query execution thread pool, which is physically isolated from the main business thread pool that processes other types of requests from the terminal, excluding the long-time query request. The asynchronous task scheduler is a singleton object that is initialized on demand; The waiting queue of the query execution thread pool includes a bounded queue; Sending the data query request to the target database via the asynchronous task scheduler includes: The asynchronous task is executed through the query execution thread pool to send the data query request to the target database.

4. The method according to claim 1, characterized in that, The step of sending the data query request to the target database and starting continuous monitoring of the target database's response to the data query request for a target duration includes: The target duration is determined based on the timeout duration threshold and the preset buffer duration.

5. The method according to claim 2, characterized in that, The step of sending a termination request to the target database and returning a prompt message to the terminal if no query result is received from the target database for the data query request within the target time period also includes: Interrupt the asynchronous task of sending the data query request to the target database and release the thread executing the asynchronous task in the query execution thread pool; Sending a termination request to the target database includes: By calling the query cancellation interface provided by the driver layer of the target database, an instruction is sent to the server of the target database to terminate the query process corresponding to the data query request.

6. The method according to claim 1, characterized in that, If no query result is received from the target database for the data query request within the target time period, a termination request is sent to the target database and a prompt message is returned to the terminal, including: The abnormal information indicating that the query result was not received within the target time period is mapped to structured data containing business status codes and a list of operation suggestions to obtain the prompt information.

7. A database request processing apparatus, characterized in that, The device includes: The receiving module is used to receive data query requests sent by the terminal through the gateway; the data query requests are used to request data queries in the database. The monitoring module is used to send the data query request to the corresponding target database and start monitoring the response of the target database to the data query request for a continuous target duration; wherein, the target duration is less than the timeout duration threshold of the gateway; the timeout duration threshold is used to characterize the maximum waiting time of the gateway before disconnecting the connection with the terminal when no response result of the data query request is received; The sending module is configured to send a termination request to the target database and return a prompt message to the terminal if no query result is received from the target database for the data query request within the target time period; wherein, the termination request is used to request the target database to stop executing the data query request; the prompt message includes indication information of the query timeout status of the data query request and reconstruction suggestion information for the data query request.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images