问题描述
使用Grails 2.3.9（Groovy（2.2.2），Mysql 5.5.37（MySQLUTF8InnoDBDialect），JDK 1.7我试图实现并测试乐观锁定功能来自Grails / Hibernate在控制器端。在我的直觉以下
def instance = Group.findByXXX（...）
instance.properties = params
// ...
instance.version = 5 //比当前
instance.save flush：true，failOnError：true
会抛出异常因为版本错误。但是，无论如何都保存实例。
这个问题可能与，只是我不理解它。这是我在阅读这个问题/答案后所尝试的：
def copyInstance = copy（instance）//我实例化一个新项目，复制所有成员s
//从实例到新的
copyInstance = copyInstance.merge（）
copyInstance.version = 5 //比当前$ b $小的东西copyInstance.save flush：true ，failOnError：true
这有预期的结果（保存失败）。但是我还是不太清楚它的含义：有人能解释上层对象实例和下层copyInstance之间的区别吗？而且，这就是乐观锁定的方式（在我看来，额外的复制可能不需要）？ Hibernate中的AFAIK锁定实际上只有在会话上下文中有两个同一持久对象的并发版本时才会发挥作用。
您的顶级示例正常工作是因为您只有一个实例，因此可以透明地监控状态，而无需锁定。 Hibernate知道你的对象不可能拥有两个不同的持久状态，因为它只有一个实例，所以它不会检查版本。它知道这个对象比数据库中的对象更新，所以它只是写入你的修改。
您的第二个实例失败，因为您有两个同一对象的实例。当您尝试使用较低版本保存第二个实例时，它会失败，因为该对象已被数据库锁定。 Hibernate将使用版本号来确定哪些对象更新，并将这些更改保存到数据库中。
Using Grails 2.3.9 (Groovy (2.2.2), Mysql 5.5.37 (MySQLUTF8InnoDBDialect), JDK 1.7
I'm trying to implement and test the optimistic locking feature from Grails/Hibernate in the controller side.
After my intuition the following
def instance = Group.findByXXX(...)
instance.properties = params
// ...
instance.version = 5 // something smaller than the current
instance.save flush:true, failOnError: true
would throw an exception is thrown because of wrong version. However, the instance is saved in any case.
This question is probably the same as this one, just that I don't understand it. This is what I tried after reading the this question/answer:
def copyInstance = copy(instance) // I instantiate a new item, copy all members
// from instance to the new one
copyInstance = copyInstance.merge()
copyInstance.version = 5 // something smaller than the current
copyInstance.save flush:true, failOnError: true
This had the expected result (saving failed). But I still don't quite see through it: could someone explain what the difference is between the upper object "instance" and the lower "copyInstance"? And, is this the way the optimistic locking is achieved (it seems to me the extra copying might not be needed)?
AFAIK locking in Hibernate really only comes into play when you have 2 concurrent versions of the same persisted object within the session context.
Your top example works because you only have the one instance, so it's state can be transparently monitored without the need for locking. Hibernate knows that there is no possibility of your object having two different persisted states because there is only one instance of it, so it doesn't bother to check the version. It knows that this object is newer than what is in the database so it just writes your changes.
Your second instance fails because you have 2 instances of the same object. When you try to save the 2nd instance with the lower version, it fails because the object has been locked by the database. Hibernate will use the version number to determine which of the objects is newer, and persist those changes to the database.
这篇关于Grails / Hibernate：控制器中的乐观锁定的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！