我们的应用程序主要使用 Hibernate 版本控制支持的乐观锁定。我们计划在一种特定场景中实现悲观锁定。我在悲观锁定方面没有太多经验，所以如果这个问题听起来很幼稚，请原谅。
当用户表现出更新条目的意图时 - 我们使用“选择更新”锁定相应的数据库行。现在，如果这个用户花了很长时间来提交他的更改，并且在锁定后忘记了它，我们如何使用某种超时/回滚机制来解锁这个锁？这样该行就不会长时间保持锁定状态并不允许所有其他用户对其进行编辑。
我怀疑这是否会在我们正在使用的 Weblogic-JTA-Spring 事务机制中处理 - 我们已经有 30 分钟的事务超时。 (？)
那么，这个回滚是否应该直接在 Oracle 级别处理。如果是，那么如何？请建议处理此问题的最佳方法，以便此类锁不会停留太久。
最佳答案
只有当事务结束时才会释放锁。当向数据库发出显式提交或回滚时，或者当数据库 session 终止时(这会执行隐式回滚)，事务将结束)。如果您的中间层已设置为回滚任何打开时间超过 30 分钟的事务，则足以释放锁定。
但是，如果您有一个在 Weblogic 应用程序服务器中运行的 Java 应用程序，那么悲观锁定的适用性让我觉得不寻常。首先，我假设您在中间层使用连接池。如果是这种情况，则连接池中的一个数据库连接需要由中间层在整个事务期间(在本例中最多 30 分钟)保留。但是，允许一个 session 长时间保持打开特定的数据库 session 就违背了连接池的目的。通常，数十个甚至数百个应用程序 session 可以共享连接池中的单个连接 - 如果您要允许悲观锁定，那么您现在将在这些 session 的应用程序 session 和数据库 session 之间强制建立 1:1 关系。
关于java - 如何在Oracle中回滚/超时 “select for update”锁？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14493912/