There are three possible causes for this SQLException:
Cause 1. If your DBMS becomes and remains unavailable, the data source will test and try to replace dead connections while trying to satisfy connection requests. This behavior is beneficial because it enables the data source to react immediately when the database becomes available. However, testing a dead database connection can take as long as the network timeout, and can cause a long delay for clients.
To minimize this delay, the WLS data sources include logic that disables the data source after 2 consecutive failures to replace a dead connection. When an application requests a connection from a disabled data source, WebLogic Server throws a PoolDisabledSQLException immediately to notify the client that a connection is not available.
Cause 2. There is a known issue addressed by unpublished defect 8174835. When an application retrieves a connection from the JDBC pool, the implementation will check if it thinks that the connections are hanging. The check is based on pending tests that takes more time than is 'typical.' And typical means the max time for the last 10 successful tests. The problem is that a test can either be a local java call that returns immediately or it can query the database. So the worst case is when a system has a burst of connection requests, but the last 10 successful tests are local calls that we can assume takes less than 1 ms. In this case we wait about 20 ms (a loop of 20 iterations is performed) before we assume that the connection is hanging. And at high loads it is not uncommon that the DB query takes more than that time.
Cause 3. There is another known issue addressed by Bug 8188896. The JVM will occasionally, for a brief period during GC, halt all threads, including our connection tests, which may have been taking 1-2 milliseconds consistently for hours, but for this brief period may have to wait multiple seconds before getting their successful response. Our pool code, which is designed to protect against DBMS partition and network hangs that can last for minutes, was relying on tests to always take about as long, and they don't, so this code was disabling a pool that would be fine within 5-10 seconds.The new code will allow for a test to take up to 10 seconds maximum now, by default, and this can either be extended, or made essentially unlimited by a command-line option added to the line that starts java for the server: