java - 对 Oracle 11g 的 JDBC 请求虽然表面上成功但未能提交

Question

我们有一个较旧的基于 Web 的应用程序(带有 Spring 2.5.4 框架的 Java)，在 GlassFish 3.1(版本 43)服务器上运行。该应用程序最近(几周前)被重定向为使用 Oracle 11g (11.2.0.3.0) 数据库和 ojdbc6.jar/orai18n.jar(从 Oracle 10g 10.2.0.3.0 和 ojdbc14.jar 升级) - - 使用 JDBC 瘦连接。该应用程序使用 org.apache.commons.dbcp.BasicDataSource 版本 1.2.2 进行连接，数据库请求通过 Spring jdbcTemplate(通过 JdbcDaoSupport 抽象类)或 Spring 的 PlatformTransactionManager 处理。

今天早上，我们注意到应用程序用户能够输入信息、修改信息，然后通过应用程序检索和打印该数据，但在过去 24 小时内没有提交的更新。该应用程序目前每天只有几个用户，并且他们显然共享同一个连接，该连接在最后一天由连接池保持打开状态，因此他们未提交的更新通过应用程序可见，但不能通过与数据库的其他连接可见。当连接关闭时，未提交的更新将丢失。

检查服务器日志显示，从上次提交数据库更改的时间到第二天早上打印报告的时间没有错误。此外，即使(以某种方式)通过将 JDBC 连接设置为 Auto-Commit false 进行了一些更改，也对属于事务一部分的某些更新进行了特定提交，作为尝试的一部分/catch block 应该执行“transactionManager.commit(transactionStatus);”之一或“transactionManager.rollback(transactionStatus);”必须已无错误地处理的调用。 看起来好像提交成功返回，但实际上没有发生提交。

重新启动 GlassFish 域，应用程序恢复正常操作，并在输入时提交各种更新。

我的问题是有人看到或听说过类似的事情发生吗？如果是的话，可能是什么原因造成的？

感谢您在这里提出的任何想法 - 我们不知所措。

<小时/>

一些新信息:

1. 对 Oracle 11g 服务器的检查表明，在我们认为提交似乎停止的时间附近，有四个操作在我们无法完全解决的其他操作上被阻止，但可能是更新.

2. 对 Glassfish Server 日志的检查表明，工作线程的外观在估计的开始时间之后发生了变化，并且日志中出现的线程越来越少，直到只有一个线程持续使用了几个小时。

3. 大约一周后问题再次出现，大约 1/2 小时后被发现。此时有两个工作线程在运行。

Answer 1

该问题是由两件事共同造成的。第一个是设置 Spring 事务的方法，但有一个绕过 TransactionManager.commit() 和 TransactionManager.rollback() (以及构成事务的多个 SQL 请求)的退出。虽然这确实是错误的编码，但在过去，该事务已被关闭，因此对后续使用没有影响。

解决方案是确保在无事可做的情况下不会启动事务；或者，一般来说，请仔细检查以确保所有事务一旦开始就已完成。

我不确定这个问题是如何或为什么会出现，所以以下是部分推测。显然，升级到 Oracle 11g 和/或切换到 ojdbc6.jar 驱动程序改变了错误代码的早期行为，因此事务不会终止，并且连接自动提交为 false。 (这也可能是由于我们尚未确定的其他一些变化，因为上述特殊情况很少发生，但确实发生了。)相应的 JDBC 连接似乎绑定(bind)到特定的 GlassFish 工作线程(我将其称为“坏”) ' 下面的线程而不是正常运行的“好”线程)。每当这个“坏”线程用于处理应用程序请求(对于这个特定应用程序)时，更改都不会提交并选择返回脏数据。随着时间的推移，当在“好”线程上请求更改并且 JDBC 连接已经在“坏”线程上进行了未提交的更改时，新请求将挂起，工作线程也会挂起。最终，除了“坏”工作线程之外的所有线程都被挂起，从应用程序的角度来看，一切似乎都工作正常，但没有提交任何内容。

同样，解决方案是纠正错误的代码。