如何禁用JPA的锁定系统？
我正在使用 OpenJPA，但遇到锁定问题。我已经了解什么是 OptimisticLockException 以及何时抛出它。
但我该如何处理呢？
下面*，您可以找到一小段关于乐观锁异常的内容。
简而言之，我如何才能完全禁用锁定管理器？
在我的 persist.xml 中，我有以下 xml 代码，但它不起作用。为什么 ？
...
<properties>
<property name="openjpa.LockManager" value="none" />
</properties>
...
*根据关于 Java Persistent 的 wikibooks ：
处理乐观锁异常
不幸的是，程序员常常为了自己的利益而变得过于聪明。使用乐观锁时出现的第一个问题是发生 OptimisticLockException 时该怎么办。友好邻居超级程序员的典型反应是自动处理异常。他们只会创建一个新事务，刷新对象以重置其版本，然后将数据合并回对象并重新提交。问题很快就解决了，是吗？
这实际上从一开始就破坏了锁定的全部意义。如果这是您想要的，您也可以不使用锁定。不幸的是，OptimisticLockException 很少会被自动处理，并且您确实需要就这个问题打扰用户。您应该向用户报告冲突，并要么说“抱歉，但发生了编辑冲突，他们将不得不重做工作”，或者在最好的情况下，刷新对象并向用户提供当前数据和他们提交的数据，并在适当的情况下帮助他们合并两者。
一些自动合并工具会比较数据的两个冲突版本，如果各个字段都不冲突，则数据将自动合并，无需用户的帮助。这就是大多数软件版本控制系统所做的。不幸的是，用户通常比程序更能决定何时发生冲突，仅仅因为 .java 文件的两个版本没有更改同一行代码并不意味着不存在冲突，第一个用户可能已经删除了其他用户添加了要引用的方法的方法，以及导致通常每晚构建经常中断的其他几个可能的问题。
I'm using OpenJPA and I have a lock problem. I already understand what's an OptimisticLockException and when it's thrown.
But how can I deal with it ?
Below*, you can find a small paragraph about the optimistic lock exceptions.
In a nutshell, how I can totally disable the lock manager ?
In my persistent.xml, I have the following xml code but it does not work. Why ?
...
<properties>
<property name="openjpa.LockManager" value="none" />
</properties>
...
*According to the wikibooks about the Java Persistent :
Handling optimistic lock exceptions
Unfortunately programmers can frequently be too clever for their own good. The first issue that comes up when using optimistic locking is what to do when an OptimisticLockException occurs. The typical response of the friendly neighborhood super programmer, is to automatically handle the exception. They will just create a new transaction, refresh the object to reset its version, and merge the data back into the object and re-commit it. Presto problem solved, or is it?
This actually defeats the whole point of locking in the first place. If this is what you desire, you may as well use no locking. Unfortunately, the OptimisticLockException should rarely be automatically handled, and you really need to bother the user about the issue. You should report the conflict to the user, and either say "your sorry but an edit conflict occurred and they are going to have to redo their work", or in the best case, refresh the object and present the user with the current data and the data that they submitted and help them merge the two if appropriate.
Some automated merge tools will compare the two conflicting versions of the data and if none of the individual fields conflict, then the data will just be automatically merged without the user's aid. This is what most software version control systems do. Unfortunately the user is typically better able to decide when something is a conflict than the program, just because two versions of the .java file did not change the same line of code does not mean there was no conflict, the first user could have deleted a method that the other user added a method to reference, and several other possible issues that cause the typically nightly build to break every so often.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这取决于您的应用程序...您需要做最有意义的事情。也许您需要提示用户数据已同时修改，然后使用新的（更）数据重新提交？
虽然我不认为禁用 OptimisticLocking 是正确的解决方案，但我认为设置这两个属性将消除您所看到的 OLE。
It depends on your application... you'll need to do what makes the most sense. Perhaps you need to prompt your user that the data was concurrently modified and have then resubmit with the new(er) data?
While I don't think disabling OptimisticLocking is the correct solution, I think setting these two properties will get rid of the OLEs you are seeing.