1

我们有一个较旧的基于 Web 的应用程序（Java 和 Spring 2.5.4 框架）在 GlassFish 3.1（build 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 块应该已执行“transactionManager.commit(transactionStatus);”之一 或“transactionManager.rollback(transactionStatus);” 必须已正确处理的呼叫。看起来好像提交成功返回，但实际上没有发生提交。

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

我的问题是，有没有人看到或听说过这样的事情发生，如果有，是什么原因造成的？

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

一些新信息：

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

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

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

4

1 回答 1

0

问题的发生是由于两件事的结合。第一个是设置 Spring Transaction 的方法，但有一个退出，绕过了 TransactionManager.commit() 和 TransactionManager.rollback() （以及构成事务的几个 SQL 请求）。尽管这是公认的错误编码，但在过去，此交易已关闭，因此对后续使用没有影响。

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

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

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

于 2013-11-13T13:19:20.363 回答