Tomcat 8.5下多WAR连接Oracle8的实现方式性能差异咨询

单应用独立部署场景的性能表现 #

在单个WAR独立使用连接池、没有其他应用连接同一数据库的场景下，两种实现的性能完全没有可感知的差异：

• 纯Java实现的核心逻辑，是在应用代码中直接实例化Tomcat JDBC连接池的原生 org.apache.tomcat.jdbc.pool.DataSource 类，手动配置连接参数、池容量、校验规则等属性
• JNDI Context配置的核心逻辑，是由Tomcat容器根据你写在Context里的Resource配置，初始化同一个 org.apache.tomcat.jdbc.pool.DataSource 类实例，后续通过JNDI查找把实例暴露给应用
• 两者底层的连接获取、有效性校验、闲置连接回收、连接泄漏检测的代码链路完全一致，不会出现某一种方式产生额外性能开销的情况，压测下的连接获取延迟、业务吞吐量基本处于同一水平

多WAR共享同库场景的能力差异 #

当后续有多个WAR包需要连接同一套Oracle8数据库时，两种方式的实际资源开销和管理便利性会出现明显差距，这也是两类方案的核心分水岭：

纯Java实现的固有局限 #

• 每个WAR的类加载器是独立隔离的，如果每个应用都在自己的容器内初始化连接池，会为同一个数据库生成N份完全独立的连接池实例
• 这种分散模式下，每个连接池为了应对业务高峰，都会预留一定量的冗余连接，整体连接数会远超数据库的实际承载需要；尤其是Oracle8这类老版本数据库，单实例最大连接数上限本就不高，很容易出现多应用连接打满数据库配额的问题
• 分散的连接池没有统一管控入口，调整池容量、排查连接泄漏、处理数据库连接抖动时，需要逐个登录每个应用的配置入口修改，运维成本很高

JNDI Context配置的管理优势 #

• 你可以将连接池Resource配置为Tomcat全局资源，所有部署在该Tomcat实例上的WAR包，通过标准的JNDI引用就能拿到同一个连接池实例，不需要每个应用单独初始化连接池
• 这种共享模式下，整个Tomcat实例对同一数据库只维护一份连接池，总连接数由统一规则管控，不会出现多应用争抢连接的问题；而且因为只需要配置一份池的冗余容量，整体对数据库的连接开销反而比多应用独立建池的纯Java模式更低
• 连接池的生命周期由Tomcat容器统一托管，不需要每个应用单独写初始化、销毁的钩子逻辑，后续新增WAR包接入同一数据库时，只需要在应用的资源引用配置里声明对应名称，就能直接复用现有连接池，不需要重复写连接池初始化代码

适配你当前环境的实操提示 #

• 不管选择哪种实现方式，使用ojdbc8驱动时，都需要将驱动包放到Tomcat的公共类路径下，也就是 $CATALINA_HOME/lib 目录，避免类加载器隔离导致的驱动找不到问题
• 如果出于历史遗留原因必须选择纯Java实现，又要对接多个WAR的同库场景，需要自行将连接池实例托管在Tomcat的公共类加载作用域内，否则很容易出现多应用独立建池打满数据库连接的问题

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