为什么应始终将连接池与Oracle XE一起使用

介绍

Oracle Express Edition是Oracle Enterprise Edition的免费版本，其较小的尺寸使其非常方便地测试各种Oracle功能。

根据Oracle文档 ，Express Edition最多可以使用一个CPU和1 GB RAM，但是实际上存在其他限制并不总是很明显。

数据库连接处理异常

以下测试试图模拟低延迟的事务环境，因此租用了连接，但时间非常短：

private void simulateLowLatencyTransactions(
        DataSource dataSource, int waitMillis) 
        throws SQLException {
    for (int i = 0; i < callCount; i++) {
        try {
            try (Connection connection = 
                 dataSource.getConnection()) {
                //Let's assume we are running a
                //short-lived transaction
                sleep(waitMillis);
            }
        } catch (SQLException e) {
            LOGGER.error("Exception on iteration " + i, e);
        }
    }
}

此测试可以正常工作，直到将等待时间降低到超过某个阈值为止，在这种情况下，数据库偶尔会开始引发以下异常：

ERROR  [main]: c.v.b.h.j.c.OracleConnectionCallTest - Exception on iteration 111
java.sql.SQLException: Listener refused the connection with the following error:
ORA-12516, TNS:listener could not find available handler with matching protocol stack
 
    at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:489) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:553) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:254) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:32) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:528) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at oracle.jdbc.pool.OracleDataSource.getPhysicalConnection(OracleDataSource.java:280) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at oracle.jdbc.pool.OracleDataSource.getConnection(OracleDataSource.java:207) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at oracle.jdbc.pool.OracleDataSource.getConnection(OracleDataSource.java:157) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at com.vladmihalcea.book.high_performance_java_persistence.jdbc.connection.OracleConnectionCallTest.simulateLowLatencyTransactions(OracleConnectionCallTest.java:50) [test-classes/:na]
    at com.vladmihalcea.book.high_performance_java_persistence.jdbc.connection.OracleConnectionCallTest.testConnections(OracleConnectionCallTest.java:40) [test-classes/:na]

尽管代码是单线程的，但是Oracle开始抱怨连接请求侦听器找不到用于处理传入请求的进程处理程序。

可以通过将流程和会话参数提高到更高的值来证明这一假设：

alter system set processes=1000 scope=spfile;
alter system set sessions=1000 scope=spfile;

使用这些新设置，代码可以正常运行，并且不会发出异常。 尽管增加流程和会话限制可以解决问题，但是此解决方案仅是一种解决方法，它只会提高连接阈值，而不能解决根本原因。

此IBM故障排除说明给出了一种可能的解释，建议连接关闭事件可能不会立即通知连接侦听器。 这可能会导致连接侦听器错误地声明实际的连接数，并假定已经达到最大进程数。

在Oracle 11g企业版上，此问题不可复制。

解决方法

精明的读者在查看异常堆栈跟踪时会注意到该问题。 OracleDataSource不提供任何连接池机制 ，这导致大量连接在服务器端和驱动程序这两个驱动程序上建立了开销。

使用连接池解决了此问题，因为连接被重用而不是按需建立。 连接池大大减少了连接获取时间，这也导致了较低的事务等待时间和更好的吞吐量。

翻译自: https://www.javacodegeeks.com/2015/08/why-you-should-always-use-connection-pooling-with-oracle-xe.html