我们的应用程序主要使用 Hibernate 的版本控制支持的乐观锁定。我们计划在一种特定情况下实施悲观锁定。我对悲观锁定没有太多经验，所以如果这个问题听起来很幼稚，请原谅。
当用户表现出更新条目的意图时 - 我们使用“选择更新”锁定相应的数据库行。现在，如果这个用户需要很长时间来提交他的更改在锁定后忘记了它，我们如何使用一些超时/回滚机制来解锁这个锁？这样该行就不会长时间保持锁定状态，并且不允许所有其他用户对其进行编辑。
我怀疑这是否会在我们正在使用的 Weblogic-JTA-Spring 事务机制中处理——我们已经有 30 分钟的事务超时。（？？）
因此，是否应该直接在 Oracle 级别处理此回滚。如果是，那么如何？请就处理此问题的最佳方法提出建议，以免此类锁停留太久。
只有在事务结束时才会释放锁。事务将在显式commit或rollback向数据库发出或数据库会话终止（执行隐式rollback）时结束。如果您的中间层已设置回滚任何打开时间超过 30 分钟的事务，则足以释放锁定。
但是，如果您有一个 Java 应用程序在 Weblogic 应用程序服务器中运行，那么悲观锁定是合适的，这让我觉得很不寻常。首先，我假设您在中间层使用连接池。如果是这种情况，则连接池中的一个数据库连接将需要由中间层在事务长度内保持（在这种情况下最多 30 分钟）。但是允许一个会话长时间保持打开一个特定的数据库会话会破坏拥有连接池的目的。通常，数十个（如果不是数百个）应用程序会话可以共享连接池中的单个连接——如果您要允许悲观锁定，那么您现在强制这些会话的应用程序会话和数据库会话之间存在 1:1 的关系。
乐观锁不能代替悲观锁的情况很多。锁定超时在数据库中处理。有关如何在 Oracle 中配置它的信息，请参阅此页面