java JDBC对Oracle 11g的请求未能提交，尽管显然已成功

Question

我们在GlassFish 3.1（build 43）服务器上运行了一个较旧的基于web的应用程序（Java和Spring 2.5.4框架）。该应用程序最近（几周前）被重新定向为使用Oracle 11g（11.2.0.3.0）数据库和ojdbc6。jar/orai18n。jar（从Oracle10g10.2.0.3.0和ojdbc14.jar升级）——使用JDBC瘦连接。应用程序正在使用org。阿帕奇。平民dbcp。用于连接和数据库请求的BasicDataSource版本1.2.2通过Spring jdbcTemplate（通过JdbcDaoSupport抽象类）或Spring的PlatformTransactionManager进行处理

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

检查服务器日志显示，从最后一次提交数据库更改到第二天早上打印报告的时间，没有错误。此外，即使在JDBC连接设置为Auto Commit false的情况下（以某种方式）进行了一些更改，也会对属于事务一部分的某些更新进行特定的提交，作为try/catch块的一部分，这些更新应该执行“transactionManager.Commit（transactionStatus）；”中的一个或“transactionManager.rollback（transactionStatus）；”必须已正确处理的呼叫。它看起来好像提交成功返回，但实际上没有提交

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

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

谢谢你在这里提出的任何想法，我们都不知所措

---

一些新信息：

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

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

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

Answer 1

这个问题是由两件事共同造成的。第一个是设置Spring事务的方法，但是有一个绕过TransactionManager的出口。commit（）和TransactionManager。rollback（）（以及组成事务的几个SQL请求）。尽管这是不正确的编码，但在过去，该事务已关闭，因此对后续使用没有影响

解决方案是确保在无事可做的情况下交易不会启动；或者，一般来说，反复检查以确保所有事务在启动后都已完成

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

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