About Connection Pool

By | June 5th 2019 01:09:04 PM | viewed 394 times

What is Connection Pool

A connection pool is a technique used in database management to optimize the use of database connections in applications. It maintains a pool (or cache) of database connections that are reused, rather than creating and closing connections repeatedly. This improves application performance by reducing the overhead associated with opening and closing database connections.

How Connection Pool Works

  1. Initialization:

    At application startup, the connection pool creates a number of database connections (based on the configuration).

    These connections remain open and idle(when it is not being used by any program), ready to be used.

  2. Borrowing Connections:

    When an application needs to interact with the database, it requests a connection from the pool.

    If a connection is available, it is provided to the application immediately.

    If no connection is available, the pool might wait for one to be returned or create a new connection (depending on the configuration).

  3. Returning Connections:

    After the application finishes its database operations, it returns the connection to the pool.

    The pool keeps the connection alive for future requests.

  4. Cleanup:

    Idle connections that are not used for a certain period may be closed to free resources (based on the pool's idle timeout configuration).

Components of a Connection Pool

  1. Minimum Pool Size:

    The minimum number of connections that remain in the pool, even if they are idle.

  2. Maximum Pool Size:

    The maximum number of connections the pool can create.

  3. Idle Timeout:

    The amount of time a connection can remain idle before being closed.

  4. Connection Validation:

    Regular checks to ensure connections in the pool are still valid (not stale or broken).

  5. Connection Leak Detection:

    Mechanisms to detect and log connections that are checked out but not returned properly.

Popular Connection Pooling Libraries

  1. HikariCP:
  2. Apache DBCP:
  3. Tomcat JDBC Pool:
  4. C3P0:

Tools to Fine-Tune for HikariCp

  1. HikariCP metrics (via JMX or monitoring tools like Prometheus/Grafana).
  2. Database logs and tools to analyze active connections and query performance.

Oracle standard timeout related to maxLifetime of hikari

  1. Connection timeout

    The default timeout for TCP listeners is 300 seconds, and for HTTP listeners it's 60 seconds. The maximum timeout value is 7,200 seconds.

  2. Session timeout

    The default session timeout for Oracle APEX is 5 minutes (300 seconds). You can change this value by entering a positive integer or setting it to 0 to disable session timeout warnings

  3. Keep-alive timeout

    The default keep-alive timeout is 30 seconds, and the maximum is 300 seconds (5 minutes). This timeout determines how long the server will keep HTTP keep-alive connections open

  4. TimesTen client application timeout

    The default timeout is 60 seconds. You can increase this value if you're executing SQL operations that might take longer.

  5. Oracle ILOM session timeout

    The default timeout for authorized web users is 15 minutes, and for authorized command-line users it's 12 hours

  6. ADF Server timeout

    The default timeout is 20 minutes

How to download HikariCp in grails 3.X

Copy this this 'compile "com.zaxxer:HikariCP:2.7.7' and past in the build.gradle file and run the project

Add the following properties in application.yml file

dataSource:
  pooled: true
  poolName: HikariPCPool
  jmxExport: true
  #logSql: true
  #formatSql: true
  driverClassName: oracle.jdbc.OracleDriver
  dialect: org.hibernate.dialect.Oracle10gDialect
  username: *******
  password: *******
  dbCreate: update
  hikari:
    maximumPoolSize: 20           
    minimumIdle: 20              
    #idleTimeout: 10000          
    #connectionTimeout: 30000     
    maxLifetime: 3600000         
    connectionTestQuery: SELECT 1 
    validationTimeout: 5000       
    leakDetectionThreshold: 1200000  
    jmxEnabled: true              
    testOnBorrow: false           
    testOnReturn: false           
    testWhileIdle: false          
    validationQuery: SELECT 1     
    validationQueryTimeout: -1    
    timeBetweenEvictionRunsMillis: 60000 
    #minEvictableIdleTimeMillis: 900000 
    #validationInterval: 3000  
    #jdbcInterceptors: ConnectionState

Details about hikariCp properties:

  1. maximumPoolSize: 50 -- Maximum number of connections in the pool.Optimal PoolSize=Number of Cores×(1+(Tread WaitTime/ServiceTime))(query execution)).oracle default connection limit:150
  2. minimumIdle: 5 -- Minimum number of idle connections to maintain in the pool. Avoid holding idle connections unnecessarily.By default, minimumIdle is equal to maximumPoolSize. Each idle connection consumes resources (memory, CPU, and database capacity).For small pools, minimumIdle can be closer to maximumPoolSize to ensure availability.For large pools, consider a lower minimumIdle to balance resource utilization.High/consistent traffic: Set minimumIdle closer to maximumPoolSize for availability.
  3. idleTimeout: 5000 -- Maximum time (in ms) that a connection can stay idle in the pool before it is closed.max time to keep idle connections (in ms and 1000=1seconds).High traffic, consistent load:10–30 minutes,Low traffic, bursty load:2–5 minutes, Resource-constrained environment:30 seconds – 2 minutes,Database with strict connection limits:1–5 minutes
  4. connectionTimeout: 15000 -- The connectionTimeout in HikariCP specifies how long the application should wait to obtain a connection from the pool before throwing a SQLException.Default Value: 30 seconds (30,000 milliseconds).If no connection is available within this time The application will throw an exception.Use a lower connectionTimeout (e.g., 2,000–5,000 ms) to fail fast and handle errors gracefully in real-time systems.For applications that can tolerate longer wait times, use higher values (e.g., 60,000 ms or more).
  5. maxLifetime: 60000*15 -- The maxLifetime setting in HikariCP determines the maximum lifetime of a connection in the pool. Once a connection has been in the pool for longer than maxLifetime, it is closed and replaced with a new connection. Properly configuring maxLifetime ensures the pool avoids stale connections while maintaining efficient resource usage.Connections can become stale or unusable over time due to Network interruptions,Database-side timeouts,Load balancer reconfigurations.High-Traffic Applications Use shorter maxLifetime values to ensure connections are cycled regularly and don’t become stale E.g., 15–30 minutes.Low-Traffic Applications A longer maxLifetime might be acceptable, but ensure it’s still below the database timeout.E.g., 1–2 hours.
  6. connectionTestQuery: SELECT 1 -- A connectionTestQuery is a query executed to validate that a database connection is alive and functioning correctly. This query typically runs when initializing or checking a connection in a connection pool.
  7. validationTimeout: 5000 -- validationTimeout refers to the maximum amount of time that the application will wait for a connection to be validated(connectionTestQuery).2-5 seconds is usually a good balance.This is long enough to allow a slightly delayed database or service to respond.
  8. leakDetectionThreshold: 30000 -- leakDetectionThreshold is used for checking 1.Connections are properly closed and returned to the pool., 2.Your application doesn't run out of available connections due to unreturned connections. 3.Issues like memory leaks, performance degradation, or database exhaustion are avoided. If your application often runs long-running queries, increase it (e.g., to 10-30 seconds). If your queries are expected to be very fast, reduce it (e.g., to 1-2 seconds).
  9. jmxEnabled: true -- enable jvm setting
  10. testOnBorrow: false -- It ensures that every time a connection is borrowed (checked out) from the pool, the pool runs a validation query (like SELECT 1) to verify the connection's health before giving it to the application. To prevent the application from using a stale or broken connection. To ensure reliability in environments where connections may time out or drop unexpectedly. For high-traffic environments, the recommended approach is not to enable testOnBorrow directly for every connection request
  11. testOnReturn: false -- Ensures the connection is still valid after being used.Prevents broken or stale connections from re-entering the pool.
  12. testWhileIdle: false -- testWhileIdle is a setting in some connection pool libraries that validates database connections while they are idle in the pool.
  13. validationQuery: SELECT 1 -- A validationQuery is a lightweight SQL query (e.g., SELECT 1;) executed by a connection pool to check whether a database connection is valid and responsive before it is borrowed by the application. To detect and discard stale or broken connections.To ensure the application only uses healthy connections from the pool.
  14. validationQueryTimeout: -1 --validationQueryTimeout specifies the maximum time (in seconds) allowed for a validation query to execute before it is considered failed.Purpose of validationQueryTimeout:To improve the reliability of connection validation. To prevent long delays caused by unresponsive databases during connection validation. For bots handling high traffic Set a Short validationQueryTimeout: Use a low value (e.g., 1-2 seconds) to quickly detect and discard unresponsive connections.Avoid Overloading the Database: Ensure validation queries are lightweight (e.g., SELECT 1;).
  15. timeBetweenEvictionRunsMillis: 0 --timeBetweenEvictionRunsMillis specifies the interval (in milliseconds) at which a connection pool performs a background sweep to Remove stale connections (connections that have been idle for too long or are invalid), Validate the health of idle connections (if validation is enabled),Manage pool size by reclaiming unused resources. f set to a positive value, the background task runs periodically at the specified interval. If set to 0 or negative, the eviction thread is disabled.
  16. minEvictableIdleTimeMillis: 0 -- minEvictableIdleTimeMillis specifies the minimum amount of time (in milliseconds) a connection can sit idle in the pool before it becomes eligible for eviction (removal) by the pool's cleanup thread.Set Idle Time Threshold: Use a reasonable threshold to balance connection reuse and resource efficiency.
  17. validationInterval: 3000 --? Specifies the minimum interval (in milliseconds) between successive validation checks for the same connection.When a connection is borrowed from the pool, HikariCP checks its health by default. However, instead of running a validation query every single time, validationInterval ensures that the connection is only revalidated if it hasn't been validated within the specified interval.This reduces the overhead of frequent validation, especially in high-traffic environments. For high-traffic bots, a shorter interval (e.g., 5–10 minutes) ensures connections remain healthy without excessive load. For low-traffic bots, a longer interval (e.g., 20–30 minutes) reduces unnecessary validation checks.
  18. jdbcInterceptors:"com.zaxxer.hikari.metrics.MetricsTracker,com.example.CustomInterceptor" -- jdbcInterceptors is a configuration parameter in HikariCP that accepts a list of interceptor class names. These interceptors are used to intercept JDBC calls made to the database and can modify the behavior of those calls or log additional information.Common Use Cases for jdbcInterceptors:Monitoring: Collect detailed metrics on the performance of queries, connection pool usage, or other database interactions. Logging: Automatically log SQL queries, error messages, or connection details for debugging and auditing. Custom Validation: Automatically apply certain checks on queries or connections before they are executed.
  19. registerMbeans: true --HikariCP supports Java Management Extensions (JMX), which allows you to monitor the connection pool through tools like IntelliJ’s built-in VisualVM plugin or JConsole. Install the VisualVM Launcher plugin in IntelliJ.=>Run your application in Debug mode.=>Open VisualVM through IntelliJ and look for the MBeans tab. =>Navigate to com.zaxxer.hikari -> PoolName to view real-time pool statistics.

Connection pool in tomcat load balancing server sometime make hang ?

When using Tomcat with a connection pool in a load balancing environment, a "hang" or slow response could be due to various factors. Here are some common causes and potential solutions:

  1. Database Connection Pool Exhaustion
  2. If the connection pool is exhausted and no available connections are left,it can cause threads to wait indefinitely, leading to a "hang."

    Solution:

    Increase the maximum number of connections in the connection pool. Monitor and optimize database queries to ensure they are efficient and don't hold connections unnecessarily. Ensure that connections are properly closed and returned to the pool after use.

    In application.yml of tomcat server , you can set the pool properties like:

    maximumPoolSize: 50           
    minimumIdle: 50               
    

    Or In context.xml of tomcat server , you can set the pool properties like:

    Resource name="jdbc/yourDataSource"
              auth="Container"
              type="javax.sql.DataSource"
              driverClassName="com.mysql.cj.jdbc.Driver"
              url="jdbc:mysql://localhost:3306/yourdb"
              username="yourusername"
              password="yourpassword"
              maxTotal="100"
              maxIdle="30"
              minIdle="10"
              maxWaitMillis="10000"/>
    
  3. Thread Starvation
  4. If the threads that handle incoming requests are blocked, either by database connections or other resources, it can lead to a situation where no threads are available to process new requests, causing a hang.

    Solution:

    Increase the number of available worker threads in Tomcat by adjusting the maxThreads attribute

    In application.yml of tomcat server , you can set the pool properties like:

    maximumPoolSize: 50           
    minimumIdle: 50                
    

    Or Go to in the server.xml of tomcat server configuration file:

    Connector port="8080" protocol="HTTP/1.1"
               maxThreads="200" minSpareThreads="25"
               connectionTimeout="20000" redirectPort="8443" />
    

    Check for any deadlock situations or blocking operations in your code or database queries.

  5. Load Balancer Configuration
  6. If you're using a load balancer in front of multiple Tomcat instances, incorrect load balancing configuration or session stickiness issues could result in uneven distribution of traffic, causing some instances to become overloaded while others are underutilized.

    Solution:

    Ensure sticky sessions (also known as session affinity) are correctly configured if needed, so requests from the same client go to the same server.

    Configure the load balancer to distribute traffic evenly across all Tomcat instances.

  7. Connection Pool Misconfiguration
  8. Sometimes misconfigured connection pool settings can lead to inefficient connection management, like improper timeouts or maximum wait times, causing delays in obtaining a connection and eventually leading to a hang.

    Solution:

    Set appropriate values for maxWaitMillis (maximum time a connection can be borrowed before timing out) and validationQuery (query to check if the connection is valid before borrowing it).

    In application.yml of tomcat server , you can set the pool properties like:

          
    connectionTimeout: 30000   #30 seconds
    idleTimeout: 60000*10      #10 min  
    maxLifetime: 3600000       #1 hours          
    

    Or In context.xml of tomcat server , you can set the pool properties like:

    Resource name="jdbc/yourDataSource"
              auth="Container"
              type="javax.sql.DataSource"
              driverClassName="com.mysql.cj.jdbc.Driver"
              url="jdbc:mysql://localhost:3306/yourdb"
              username="yourusername"
              password="yourpassword"
              maxTotal="50"
              maxIdle="20"
              minIdle="5"
              maxWaitMillis="5000"
              validationQuery="SELECT 1" />
    
  9. Tomcat Resource Leaks
  10. If connections or resources aren't being cleaned up properly (e.g., connections not closed properly, or thread leaks), it can eventually cause the system to hang as resources become exhausted.

    Solution:

    In application.yml of tomcat server , you can set the pool properties like:

          
    connectionTimeout: 30000   #30 seconds   
    leakDetectionThreshold: 1200000 // 12 min  
    

    Or In context.xml of tomcat server , you can set the pool properties like:

    Resource name="jdbc/yourDataSource"
              logAbandoned="true"
              removeAbandoned="true"
              removeAbandonedTimeout="60" />
    
  11. JVM and Garbage Collection Issues
  12. A misconfigured JVM or garbage collection (GC) behavior can cause performance degradation and potential hangs, especially under heavy load.

    Solution:

    Monitor the JVM and GC logs to check for any long GC pauses or other issues that might be causing delays. Adjust JVM settings for optimal garbage collection tuning, such as adjusting heap sizes or choosing a different GC strategy like G1GC for better performance in high-load situations.

  13. Database Connectivity Issues
  14. Ensure there are no network-related issues between Tomcat and the database server. Connection timeouts or network partitioning could cause hangs if connections are not established correctly.

    Solution:

    Ensure your database server is reachable and has sufficient resources (e.g., CPU, memory). Set appropriate timeouts and retry logic for the database connection.

  15. Application Code Issues
  16. Sometimes, issues in your application code, like deadlocks, infinite loops, or other blocking operations, can cause the application to hang.

    Solution:

    Profile the application using a tool like VisualVM or JProfiler to track down slow or blocking operations. Review your application code to ensure that you are handling resources efficiently and that you don't have blocking or deadlocking code patterns. By addressing these potential issues, you can improve the performance and reliability of your Tomcat-based load-balanced environment and reduce the chances of experiencing hangs or slowdowns.

bONEandALL
Visitor

Total : 34402

Today :26

Today Visit Country :