EJB3+Oracle项目CallableStatement首次执行无响应后续正常问题求助

安全阿岳

2026-9-30

问题根因

自定义CallableStatement缓存设计完全不符合JDBC规范与容器管理逻辑：CallableStatement与对应的Connection绑定，你使用JTA事务托管的EntityManager，事务结束后Connection会自动返回连接池，缓存的CallableStatement实际绑定的是已失效的连接。同时业务代码在finally中直接关闭返回的CallableStatement，缓存中留存的是已关闭的无效实例，进一步引发资源状态异常。
手动关闭容器托管的JDBC连接：在close()方法中直接关闭从EntityManager获取的连接，破坏了JBoss连接池的生命周期管理，首次调用时可能触发连接池的失效连接清理、资源竞争逻辑导致无响应，后续复用连接时反而规避了该问题。
缓存使用非线程安全的HashMap存储，并发场景下会出现扩容、死链等问题，进一步加剧阻塞概率。
Oracle存储过程首次调用时需要进行硬解析、生成执行计划，如果涉及的表统计信息缺失、存储过程逻辑复杂，就会出现首次执行超时，后续复用执行计划则运行正常的情况。
绕过JPA规范直接获取Hibernate底层Connection的操作，会打破容器的事务上下文绑定逻辑，首次调用时的事务初始化也可能出现阻塞。
当前使用@Stateful有状态EJB，Bean实例会长期持有Session、缓存的Statement等资源，长期运行后更容易出现资源失效问题，当前场景无状态EJB即可满足需求。

解决方案

删除自定义CallableStatement缓存逻辑，容器与JDBC驱动本身已经提供了生产级的Statement缓存能力，自行实现的缓存只会引入不可控的资源问题，修改后的prepareCall方法如下：

@SuppressWarnings("deprecation")
protected CallableStatement prepareCall(String sqlString) throws SQLException {
    SessionImplementor sessionImplementor = (SessionImplementor) entityManager.getDelegate();
    Connection conn = sessionImplementor.connection();
    return conn.prepareCall(sqlString);
}

删除callableStatementCache相关的所有缓存逻辑，也不要手动缓存Session、Connection实例，每次调用都从当前EntityManager获取对应事务的有效连接。

删除手动关闭连接的逻辑，容器托管的连接不需要业务代码关闭，事务结束后会自动返回连接池，修改close()方法仅处理Session的断开逻辑即可：

public void close() {
    if (session != null) {
        if(session.isOpen()){ 
            session.disconnect();
        }
        session = null;
    }
}

优先使用JPA标准的存储过程调用API，避免直接操作底层JDBC连接，代码示例如下：

public void invokeImportPriceFromTempTableProcedure(int sessionId, String userID) throws DataException {
    try {
        StoredProcedureQuery query = entityManager.createStoredProcedureQuery("CPRPA_TPT_PRICE_CALC.tpt_data_import");
        query.registerStoredProcedureParameter(1, Integer.class, ParameterMode.IN);
        query.registerStoredProcedureParameter(2, String.class, ParameterMode.IN);
        query.setParameter(1, sessionId);
        query.setParameter(2, userID);
        query.execute();
    } catch (SQLException e) {
        throw new DatabaseException("Database exception occured!" + e);
    } catch (RuntimeException e) {
        throwDataException(e);
    }
}

Oracle侧优化：

收集存储过程涉及所有表的统计信息，避免首次执行硬解析过慢：

exec dbms_stats.gather_schema_stats(ownname => 'CPRPA_TPT_PRICE_CALC', cascade => true);

检查存储过程首次执行时的等待事件，确认是否存在锁、IO等待等问题，可通过Oracle实时会话监控、AWR报告定位瓶颈。

JBoss配置优化：在数据源配置中开启官方的Statement缓存能力，替代自行实现的缓存：

<datasource ...>
    <!-- 其他配置 -->
    <prepared-statement-cache-size>100</prepared-statement-cache-size>
    <share-prepared-statements>true</share-prepared-statements>
</datasource>

将@Stateful有状态EJB改为@Stateless无状态EJB，当前场景没有需要保留的会话状态，无状态Bean的实例池管理机制更适合这种短事务的接口调用，避免长期持有资源导致的异常。

内容的提问来源于stack exchange，提问作者Dorian Haxhiaj