IBM WebSphere Application Server establishes and maintains pools of connections as specified by the administrator.
After the connections are set up, the product manages them by parceling out connections in response to user requests and then performing housekeeping operations to maintain a balance between available connections and demand for connections. This ensures that an existing connection is available when a servlet or application server needs a connection.
For example, the connection pool periodically identifies idle or orphaned connections. It terminates idle connections and returns orphaned connections to the connection pool. This means that fewer connections are available (and fewer resources are used) when demand for connections is low.
An idle connection is one that has been free in the connection pool for the amount of time specified in the idleTimeout property of the data source. Idled connections are removed from the pool and closed to the database.
A connection is orphaned when its owning servlet or application has not used the connection for longer than the amount of time specified in the orphanTimeout property of the data source. Orphaned connections are returned to the pool of free connections. Any use of an orphaned connection or its associated JDBC resources results in a StaleConnectionException being thrown.
At the end of a transaction, the transaction manager closes all connections that have enlisted in that transaction. This enables the transaction manager to ensure that connections are not held for long periods of time, which tends to force the pool size up. As a result, an application cannot obtain a connection in one transaction and try to use it in another transaction. If the application tries this, a StaleConnectionException is thrown, because the connection is already closed.
However, if the application must hold a connection outside the scope of the transaction, the administrator can configure a datasource not to automatically clean up the connections it has allocated. To do this, the administrator sets the disableAutoConnectionCleanup property on a datasource to true. This property should be enabled only if the application will always close its own connections. Otherwise, the pool will quickly run out of connections.
If your application typically requires two or more connections to the same database manager, consider the following:
This function is most suitable for an application that runs at a steady state with a stable number of connections in the connection pool, but needs to protect the workload capacity of the database server. If the database server's workload increases from some external source, for instance some sort of traditional report generation, the transaction times for the web application might increase. As these transaction times increase, the rate at which connections are returned to the connection pool slows. This means that at any given time fewer free connections are in the pool to service new requests. Consequently, new requests cause the connection pool to create new connections to handle the requests from the application. This extra work for the database server, creating new connections and running even more concurrent transactions, might be difficult for the database server to handle. In this scenario of temporary increased database server workload, it might be best to slow the growth rate of the application server's connection pool at the expense of application responsiveness until the temporary database server workload subsides.
When you turn the surge protection on, a request for a connection that results in the connection pool creating a new connection is forced to wait for a number of seconds that you specify. After the specified interval, one waiting request is allowed to create a new connection to the database if there is room in the pool. Only requests that result in the creation of a new connection in the connection pool are affected. Connections that are returned to the pool are handed out again to these waiting requests without delay.
The waiting requests might timeout while waiting to get a connection. The requests wait for the amount of time specified by the connectionWaitTimeout property before they timeout.
Two custom datasource properties enable this function. The first is surgeThreshold. Setting the surgeThreshold to some positive integer less than the value specified by the maxPoolSize property sets a boundary within the connection pool. If a request is made to create a new connection while the total number of connections in the pool is below this boundary, no restrictions apply. However, if the total number of connections in the connection pool is at or above this boundary, the creation of a new connection is restricted by the surgeTime property. This property has a default value of 20, which indicates that 20 seconds must pass between the creation of connections. For more information about datasource properties, see 6.6.14.0.1: Properties of data sources.
In general, when the number of connections in the connection pool increases beyond the surgeThreshold , the creation of new connections is restricted. When the number of connections drops below the surgeThreshold the creation of new connections is unrestricted. Outside of the connection pool being destroyed when the application server is shut down, there are only two scenarios where the number of connections in the pool will drop below the threshold after it has been reached and unrestricted creation of new connections occurs.
The first scenario occurs when connections are removed from the pool by the idle timeout property. This case indicates that the workload either in the application server or the database server has changed such that fewer connections in the pool are needed to service the requests. When the number of connections in the pool is reduced to a number below the surgeThreshold because of the idle timeout, requests requiring the creation of a new connection are allowed to proceed unrestricted until the threshold is again reached..
The second scenario is more complex. If the connections in the pool exceed the number specified by the surgeThreshold, and then a stale connection exception empties the pool of its connections, the creation of new connections after the stale connection exception are still restricted. Often, immediately following a stale connection exception, a spike in the number of new connection requests hits the database server. If the threshold was surpassed before the stale connection exception, the database server was most likely running under some temporary increased workload. Allowing a spike of new connection requests is probably not wise. However, it is possible that during ramp up of the number of connections in the connection pool the increased workload affecting the database server could end, making the surge protection feature no longer necessary. So, after a stale connection exception, the connection pool keeps track of how many times a new connection might have been created. If this number exceeds the surgeThreshold, but the connection pool containes less than the threshold number of connections, then the surge protection feature is turned off and the creation of new connections is allowed to proceed unrestricted until the surgeThreshold is reached again