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

我们有一个 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

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

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

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

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

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