Database Connection Pool connection selection strategy (FIFO/MRU vs FILO/LRU) in JBoss EAP

Solution Verified - Updated

Environment

  • Red Hat JBoss Enterprise Application Platform (EAP)
    • 6.x
    • 7.x

Issue

  • EAP 6 is keeping more database connections alive than EAP 5
    • IdleRemover is not removing as many connections in EAP 6 as EAP 5
  • EAP 6.1.0 is keeping more database connections alive than EAP 6.0.x
  • Database connections are not closed (timed out), even if the load is less and not all connections are needed
  • Connections are not closed even if the CLI command /statistics=pool:read-attribute(name=InUseCount) shows that there is a minimal load

Resolution

Content from issues.jboss.org is not included.JBJCA-1005 introduced a change in the connection retention strategy that can be confusing for those expecting the behavior to be similar to earlier versions of EAP.

Pre JBJCA-1005 (before EAP 6.1.0)

Uses a Last In, Last Out (LIFO) based model, so it will only keep <min-pool-size> active, since connections have a better chance of timing out. i.e. keeping them cold.

This means that during the use of concurrent connections, the first connection that is created and then returned to the pool (returning to the pool != the physical connection being closed) will keep getting pushed farther away from being handed out as a connection to a client as other connections are returned. So, the "first" connection will be the most likely to be claimed by the idle connection remover.

Post JBJCA-1005 (EAP 6.1.0 or later)

Uses a First In, First Out (FIFO) based model, so it will try and keep <max-pool-size> active. If the pool is inactive the connections will start to be timed out down to <min-pool-size>. i.e. keeping them hot. One effect of this is that connections will not be timed out as idle if they are being requested at a time interval shorter than the <idle-timeout-minutes> value.

This means that as the connections are returned to the pool (returning to the pool != the physical connection being closed), the connection will become first in the line to be handed back to a client when a connection is requested. This will be more likely to cause balanced use of the existing physical connections, so less connections will be qualified as idle.

Additionally, use-strict-min=true is used to maintain the # min-pool-size. Once the pool of connections reaches the <min-pool-size>, idle connections will not be removed. i.e. it is a way to force connections to always be in the pool.

EAP 6.4.2 and later

Note that this behavior can be reverted as described in using the ironjacamar.filo_pool_behavior system property

EAP 7

IronJacamar 1.1 (EAP 7.0 includes IronJacamar 1.3, EAP 7.1 and 7.2 include IronJacamar 1.4) introduced the "Capacity policy" feature which provides a greater control over the pool behavior via Content from issues.jboss.org is not included.JBJCA-986. This will become available in EAP 7. See EAP 7.0 Configuration Guide - 13.11. Capacity Policies for details. In EAP 7.0 and later, by default, connections are reused based on an MRU selection process and less frequently used connections may be eligible for timeout depending on other settings (e.g. min-pool-size, use-strict-min, idle-timeout-minutes, etc.).

Root Cause

Starting with EAP 6.1.0, a FIFO strategy is used so that each new getConnection() request (excluding repeating requests in a transaction) retrieves the least recently used connection.

SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.