Oracle 提交和选择之间存在滞后

Question

我们有一个 Java 工作流应用程序，它使用 Oracle 数据库来跟踪其步骤以及与其他服务的交互。 在工作流运行期间，会执行多次插入/更新/选择，有时选择不会返回更新的数据，即使插入/更新提交在成功完成之前运行也是如此。 工作流程出错后（由于数据错误），如果我们返回并通过第三方应用程序检查数据库，则会显示新的/更新的数据。 我们的提交完成和可见之间似乎存在滞后。 这种情况发生在所有工作流运行的大约 2% 中，并且在数据库使用量很大时会增加。

我们的数据库支持团队建议将参数 max-commit-propagation-delay 更改为 0，因为它默认为 700。这似乎是一个可能的解决方案，但最终并没有解决我们的问题。

该应用程序在WebSphere 上运行，并且Oracle 数据库配置为JDBC 数据源。 我们使用的是 Oracle 10.1g。 该应用程序是用 Java 1.5 编写的。

任何帮助，将不胜感激。

编辑：示例代码

DataSource ds; // spring configured

String sql = "INSERT INTO " + currentTable + " (" + stepId + ',' + stepEntryId + ", " + stepStepId + ", " + stepActionId + ", " + stepOwner + ", " + stepStartDate + ", " + stepDueDate + ", " + stepFinishDate + ", " + stepStatus + ", " + stepCaller + " ) VALUES (?, ?, ?, null, ?, ?, ?, null, ?, null)";

Connection conn = ds.getConnection();
PreparedStatement stmt = conn.prepareStatement(sql);
// set values
stmt.executeUpdate();
// close connections

// later on in the code...
Connection conn = ds.getConnection();
PreparedStatement stmt = null;
ResultSet rset = null;

String sql = "SELECT " + stepId + ", " + stepStepId + ", " + stepActionId + ", " + stepOwner + ", " + stepStartDate + ", " + stepDueDate + ", " + stepFinishDate + ", " + stepStatus + ", " + stepCaller + " FROM " + currentTable + " WHERE " + stepEntryId + " = ?";
stmt = conn.prepareStatement(sql);

stmt.setLong(1, entryId);

rset = stmt.executeQuery();
//close connections

Answer 1

默认情况下，您描述的行为应该是不可能的 - 在已提交的事务中所做的更改立即可供所有会话使用。 但是，也有例外：

1. 您是否在 COMMIT 命令中使用任何 WRITE 选项？ 如果不是，请确认 COMMIT_WRITE 初始化参数的值。 如果其中任何一个使用“WRITE BATCH”或特别是“WRITE BATCH NOWAIT”，您可能会遇到并发问题。 “WRITE BATCH NOWAIT”通常用于写入事务的速度比可能的并发问题更重要的情况。 如果您的初始化参数使用“WRITE”变体，则可以通过在提交中指定 IMMEDIATE 子句来在事务基础上覆盖它 (参见 COMMIT)

2. 尝试读取数据的事务是否在其他事务提交之前调用 SET TRANSACTION？ 使用 SET TRANSACTION 指定 SERIALIZATION LEVEL READ ONLY 或 SERIALIZABLE 将导致事务看不到调用 SET TRANSACTION 后发生的其他已提交会话中发生的任何更改 (参见 SET TRANSACTION)

编辑：我发现您正在使用 DataSource 类。 我不熟悉这个类 - 我认为它是一个连接共享资源。 我意识到您当前的应用程序设计可能无法在整个工作流程中轻松使用相同的连接对象（这些步骤可能设计为独立操作，并且您没有构建一种设施来将连接对象从一个步骤传递到另一个步骤） next），但您应该验证返回到 DataSource 对象的连接对象是否“干净”，特别是对于打开的事务。 您可能没有在代码中调用 SET TRANSACTION，但其他地方的 DataSource 的另一个使用者可能会这样做，并将连接返回到数据源，而会话仍处于 SERIALIZABLE 或 READ ONLY 模式。 当连接共享时，必须先回滚所有连接，然后再将它们移交给新的使用者。

如果您无法控制或查看 DataSource 类的行为，您可能希望尝试在新获取的连接上执行 ROLLBACK，以确保它没有已建立的延迟事务。

Answer 2

如果 DBA 团队尝试修改 max_commit_propagation_delay 参数，则可能意味着您正在连接到 RAC 实例（即：多个不同的服务器访问一个数据库）。

在这种情况下，当您在 java 代码中关闭并重新打开连接时，您可能会得到不同服务器的应答。 延迟参数意味着两个实例不会处于完全相同的时间点时有一个很小的时间范围。 您得到的答案与某个时间点一致，但可能不是最新的。

正如 KM 所建议的，最简单的解决方案是在提交后保持连接打开。

或者，如果可行的话，您也可以在关闭连接后添加延迟（例如，如果这是批处理作业并且响应时间并不重要）。

Answer 3

正在使用 ORM？ 它可能是从缓存中选择的，而不是在更改后形成数据库。

Answer 4

这听起来像是 RAC 的问题，连接到两个不同的实例并且 SCN 不同步。

作为解决方法，请考虑不关闭数据库连接并获取新连接，而是重用同一连接。

如果这不起作用，则向尝试检索插入行的查询添加重试。 如果未返回该行，则休眠一下，然后再次重试查询。 将其放入循环中，在指定次数的重试后，您可能会失败。

[附录]

Steve Broberg (+1!) 在他的回答中提出了有趣的想法。 我没有考虑过：

• COMMIT可能是IMMEDIATE WAIT之外的任何内容
• 事务隔离级别可能是除了READ COMMITTED之外的任何内容

我确实考虑了闪回查询的可能性，并且立即驳回了这一点，但没有提及，因为没有明显的理由OP会使用闪回查询，并且代码片段中没有证据表明这样的事情。）

[/ADDENDUM]

Answer 5

一种可能的解决方法是使用 JTA 事务。
它通过多个打开/关闭 jdbc conns 使您的连接在“幕后”保持打开状态。 也许它会将您的连接保持在同一服务器上并避免此同步问题。

UserTransaction transaction = (UserTransaction)new InitialContext().lookup("java:comp/UserTransaction");
transaction.begin();
// doing multiple open/close cxs
transaction.commit();

Answer 6

代码片段实际上并不包含提交。

如果您假设/依赖关闭连接来执行提交，则它可能不是同步的（即，当java告诉Oracle关闭连接时，java可能会报告连接已关闭，这意味着它可能是在提交完成之前）甲骨文）。

Answer 7

我在你的代码中没有看到任何提交。 它们是此类应用程序中最重要的语句，因此我希望每次都明确地编写它们，而不是依赖于 close() 等。

您还可以在连接上默认将自动提交设置为 true，这将准确解释该行为（它在每次插入/更新后提交）。

您能否检查一下您是否已准确提交到您想要的位置，例如在事务结束时而不是之前？

如果在部分完成时有提交，那么线程之间就会出现竞争条件，这也可以解释为什么当负载较大时会出现更多问题。

Answer 8

“即使插入/更新提交在成功完成之前运行。”

这对我来说意味着您正在发出 commit()，然后期望再次读取完全相同的数据（这是可重复读取）。

这对我来说意味着你不应该做出承诺。 只要您想确保没有其他任务能够修改您明确希望保持稳定的任何数据，您就无法释放锁（这就是提交所做的）。

请注意，当您锁定某些资源时，其他线程将堆积起来“等待该资源变得可用”。 当您释放锁时，该堆栈非空的可能性随着一般系统负载的增加而增加。 当您（最终）发出“提交”时，您的 DBMS 将得出这样的结论：“嘿，哇，这个人终于完成了这个资源，所以现在我可以让所有其他等待的人尝试做他们的事情（并且没有什么可以阻止“他们的事情”更新！）”。

也许我忽略了与 Oracle 快照隔离有关的问题。 抱歉，如果是这样。