k2v-academy / K2View-Academy

Other
0 stars 0 forks source link

Different jdbc sessions stats under statistics page #995

Closed pWIqmFHmGnqqlIyFDwZIlw1JWRHoo8AgicH1IWD closed 9 months ago

pWIqmFHmGnqqlIyFDwZIlw1JWRHoo8AgicH1IWD commented 9 months ago

What is the difference between jdbcIdleSessions, jdbcActiveSessions and jdbcMaxSessions? Please explain with example, if possible. Thanks image

i7QC2njzxHCc0LYBqCh0HQf30xF2DYuJjqtFbNe commented 9 months ago

Hi,

Fabric manage connections to external sources based on apache tomcat connections pool. Maximum connections are defined for each interface per node and environment, it is set by default to 60 but can be changed by overriding the interface connection parameter in the Studio. Fabric enforce this limitation per node so it will not open more connections than the maximum defined. The connection pool is initialized in lazy mode on the first use (not in the deploy). It is possible to configure the minimum number of connections in the pool (default is 0) for performance optimization, it can be overridden on the interface parameters in Studio.

Connection is in idle status when it’s in the pool. Status can be changed in two ways:

  1. Other process consume it, so it moves to Active.
  2. Connection is removed from the pool after staying idle for 60 sec.

In case that all connections are in use (equals to the maximum), there is a defined time interval as 30000ms to wait for a connection to become available. Fabric will try to reuse connections and will use as less connections as possible. When using the syntax db(...).fetch,db(...).excute or using Broadway flows, Fabric will return each connection to the pool when query completed and will take a connection from the pool on the next query. This feature can be disabled using parameter ENABLE_SELF_CLOSE_CONNECTION (default true) = false, in this case, connection will return to the pool when sync is done and not when the command is done. To secure connection all over the activity so no one else will take it if required again. When using old syntax: DBQuery/DBSelectValue/DBExecutePrepared, the used connection will be held out of the pool since the sync start until the sync is completed.