休眠和并发答案

【问题标题】：Hibernate and Concurrency休眠和并发
【发布时间】：2010-07-09 17:09:15
【问题描述】：

我已经阅读了hibernate docs about concurrency 并且我认为我已经理解了available locking methods，但是我不确定我应该如何实现以下场景。

两个客户端 F（快）和 S（慢）访问数据库并可以修改相同的对象。

现在，还有一个额外要求：客户端 F 尽可能快地执行对应用程序至关重要。

你会如何解决这个问题？

我的乐观锁定问题：假设 F 尝试更新其更改但无法成功执行此操作，因为 S 已经更新了其数据。一个异常 (StaleObjectStateException) 将从休眠中抛出。我将捕获此异常并合并更改并再次尝试完全相同的事务，对吗？然后我不喜欢 F 在成功之前重试其事务的情况，因此 F 理论上可以阻塞很长时间。我应该忽略这一点并希望这种情况在实践中很少见吗？或者我可以给我的客户一些类似数据库锁定优先级的东西吗？

Other users 可以忍受这个问题：

StaleObjectStateException（乐观锁定）...我们每 10000 次调用就会出现 3 个异常。

【问题讨论】：

如果所有线程都能够在不访问数据的情况下完成它们的工作（即修改数据库），您的应用程序是否还有问题？似乎确实如此。似乎您是在说 C 正在以某种方式修改数据库，导致 B 在没有合并的情况下无法正确完成未来的事务？也许有办法解决这个问题？有没有办法修改环境，让并发修改成为唯一的问题？
抱歉，描述不清楚：我的意思是“异常”是 OptimisticLockException 或 StaleObjectStateException（一个对象的不同版本）而不是应用程序异常

标签： database performance hibernate concurrency locking

【解决方案1】：

捕获 StaleObjectException:s 并提高线程的优先级，这应该更快。 StaleObjectException:s 应该很少见。如果这对您不起作用，请查看悲观锁定。

【讨论】：

【解决方案2】：

跳出来的第一件事是，如果您要求 A+B 尽可能快地执行，那么在捕获和处理异常时会大大减慢。这个过程非常缓慢。

我必须多次阅读您的帖子才能完全理解您的意思并提供更好的解决方案，但对于初学者来说，我会立即考虑在这种情况下不使用异常。

【讨论】：

我不认为捕捉有那么慢，但我当然想避免例外。如果两个客户端访问数据库并修改同一个对象，我应该如何避免引发 OptimisticLockException？
@Karussell：经过您的编辑，我现在更好地理解了您的问题。我现在看到您的问题领域超出了我的专业领域——我们的应用程序不为成千上万的连接/用户提供 10 或 100 多个服务。话虽如此，我的第一个直觉反应是，“让两个客户端无法访问数据库并修改同一个对象。”当然，这可能涉及悲观锁定。因此，如果您要在高流量环境中使用乐观锁定，您几乎必须容忍一小部分故障。