hibernate之控制并发访问(乐观并发控制之理解乐观策略)

最新推荐文章于 2026-08-16 13:05:31 发布

原创最新推荐文章于 2026-08-16 13:05:31 发布 · 763 阅读

0 ·

本内容遵循CC 4.0 BY-SA版权协议

收录于

hibernate

本文探讨了乐观并发控制的概念及其在多用户应用程序中的作用。详细解释了三种处理并发更新丢失的策略：最晚提交生效、最先提交生效及合并冲突更新。讨论了每种策略的优缺点，并介绍了Hibernate如何通过自动乐观锁帮助开发者实现并发控制。

hibernate之控制并发访问(乐观并发控制之理解乐观策略)

乐观的方法始终假设一切都会好，并且很少有冲突的数据修改。在编写数据时，乐观并发控制只在工作单元结束时才出现错误。多用户的应用程序通常默认为使用读取提交隔离性级别的乐观并发控制和数据库连接。只有适当的时候(例如，当需要可重复读取的时候)才获得额外的隔离性保证，这种方法保证了最佳的性能和可伸缩性。

-------------------

理解乐观策略

为了理解乐观并发控制，想象两个事务从数据库中读取一个特定的对象，并且两者都对它进行修改。由于数据库连接的读取提交隔离性级别，因此没有任何一个事务会遇到任何脏读取。然而，读取仍然是不可重复的，并且更新还是可能丢失。这是当你在考虑对话的时候要面对的问题。

假设两个用户同时选择同一块代码。对话A中的用户先提交了变化，并且对话终止于第二个事务的成功提交。过了一会儿(可能只是一秒)，对话B中的用户提交了变化。第二个事务也成功提交。在对话A中所做的改变已经丢失，并且(可能更糟的是)对话B中提交的数据修改可能已经基于失效的信息。对于如何处理对话中这些第二个事务中的丢失更新，你有3种选择：

-----

1. 最晚提交生效---两个事务提交都成功，且第二次提交覆盖第一个的变化。没有显示错误消息。

-----

2. 最先提交生效---对话A的事务被提交，并且在对话B中提交事务的用户得到一条错误消息。用户必须获取新数据来重启对话，并再次利用没有失效的数据完成对话的所有步骤。(起用版本控制之后，是使用它吗？？？？？？？？？？？？？？？)

-----

3. 合并冲突更新---第一个修改被提交，并且对话B中的事务在提交时终止，带有一条错误消息。但是失败的对话B用户可以选择性地应用变化，而不是再次在对话中完成所有工作。

-----

如果你没有启用乐观并发控制(默认情况为未启用)，应用程序就会用最晚提交生效策略运行。在实践中，丢失更新的这个问题使得许多应用程序的用户很沮丧，因为他们可以发现他们的所有工作都丢失了，而没有收到任何错误消息。

很显然，最先提交生效更有吸引力。如果对话B的应用程序的用户提交，他就获得这样一条错误消息：有人已经对你要提交的数据提交了修改。你已经使用了失效数据。请用新数据重启对话。设计和编写生成这条错误消息的应用程序，并引导用户重新开始对话，这就是你的责任了。hibernate用自动乐观锁协助你，以便每当事务试图提交在数据库中带有冲突的被更新状态的对象时，就会得到一个异常。(得到一个异常后，我是不是应该用循环让它重新执行一次比较好呢？？？？？这样设计应该比较人性化吧？？？？？？？)

合并冲突的变化，是最先提交生效的一种变形。不显示始终强制用户返回的错误消息，而是提供一个对话框，允许用户手工合并冲突的变化。这是最好的策略，因为没有工作丢失，应用程序的用户也不会因为乐观并发失败而受挫。然而，对于开发人员来说，提供一个对话框来合并变化比显示一条错误消息并强制用户重复所有的工作来得更加费时。是否使用这一策略，由你自己决定。

标签

#hibernate #数据库 #工作