IBM Support

How to configure WebSphere data source parameters when a firewall exists between application server and data source

Troubleshooting


Problem

In WebSphere Application Server a data source can be tuned so that a firewall timeout will not drop database connections and stale connections can be avoided. This can prevent occurrences of the StaleConnectionException.

Resolving The Problem

To avoid dropped connections and StaleConnectionExceptions when a firewall is present between an application server and a database, set the following connection pool properties on the data source:

Minimum Connections = 0
Unused Timeout = half the firewall timeout value (in seconds)
Reap Time = 60 seconds
Purge Policy = EntirePool

The goal is for WebSphere Application Server to remove idle connections from the connection pool before the firewall timeout causes the connections to drop. The Unused Timeout is the number of seconds that a connection can be unused or idle in the pool before it is removed. By reducing the Unused Timeout to a value less than the firewall timeout, WebSphere Application Server will remove connections before the firewall. The Reap Time is the number of seconds between runs of the pool maintenance thread, which removes connections that have reached the Unused TImeout. Reducing the Reap Time from its default value of 180 seconds to 60 seconds will result in unused connections being removed more quickly.

It is also important to set Minimum Connections to 0. Any value above 0 means that WebSphere Application Server is required to keep that many connections in the pool even after the connections have reached the Unused Timeout. As a result, those connections will remain in the pool until they are dropped by the firewall.

The Purge Policy should remain at its default value of EntirePool. This means that when a connection in the pool is dropped and a StaleConnectionException does occur, all of the connections in the pool will be purged. This allows an application to recover more quickly from stale connections.

Finally, it is recommended that all applications that get connections from a WebSphere Application Server catch the StaleConnectionException and retry the getConnection() call when it occurs. By doing this, applications can seamlessly recover from stale connections without any impact to the end users of the application.

[{"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"DB Connections\/Connection Pooling","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"9.0;8.5.5;8.0;7.0","Edition":"Edition Independent","Line of Business":{"code":"LOB45","label":"Automation"}},{"Product":{"code":"SSNVBF","label":"Runtimes for Java Technology"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"Java SDK","Platform":[{"code":"","label":""}],"Version":"","Edition":"","Line of Business":{"code":"LOB36","label":"IBM Automation"}}]

Document Information

Modified date:
15 June 2018

UID

swg21066467