如何处理锁(JPA)? [英] How to deal with locks (JPA)?

问题描述

根据 Java持久/锁定Wikibooks *，最好的处理锁的方法是向用户报告乐观锁错误/异常.

According to the Java Persistent/Locking wikibooks*, the best way to deal with locks is to report the Optimistic Lock Error/Exception to the user.

问题在于它不可扩展.假设我有许多用户可能以相同的操作导致锁定.用户不在乎锁定错误消息.

The problem is that it's not scalable. Suppose that I have many users who are likely to cause a lock with the same action. The user does not care about the lock error message.

简而言之:

• 最好的方法是禁用所有锁?
• 最好的方法是向用户报告错误锁定消息?但是用户必须重试其操作，直到操作成功！
• 最好的方法是重试交易，直到没有锁定?

*

处理乐观锁异常

Handling optimistic lock exceptions

不幸的是，程序员经常为了自己的利益而变得太聪明了.使用乐观锁定时出现的第一个问题是发生OptimisticLockException时该怎么办.友好的邻域超级程序员的典型响应是自动处理异常.他们将只创建一个新事务，刷新对象以重置其版本，然后将数据合并回该对象并重新提交. Presto问题解决了吗?

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?

这实际上击败了首先锁定的整个问题.如果这是您想要的，则最好不使用锁定.不幸的是，OptimisticLockException很少应该被自动处理，并且您确实需要打扰用户.您应该向用户报告冲突，然后说抱歉，但发生编辑冲突，他们将不得不重做工作"，或者在最佳情况下，刷新对象并向用户显示当前数据，并他们提交的数据，并在适当时帮助他们合并两者.

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.

某些自动合并工具将比较数据的两个冲突版本，如果各个字段都没有冲突，则将在没有用户帮助的情况下自动合并数据.这就是大多数软件版本控制系统所执行的操作.不幸的是，用户通常比程序更能确定何时有冲突，仅因为.java文件的两个版本未更改同一行代码并不意味着没有冲突，因此第一个用户可以删除一个另一个用户添加了一个要引用的方法的方法，以及其他可能导致通常每晚构建中断的其他可能问题.

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.

推荐答案

用户将关心消息，因为他想进行一些修改，但尚未进行修改.因此，他将刷新页面以查看数据的新状态，并重做他的修改，或决定在给出新状态后不再进行修改.

The user will care about the message, because he wanted to do some modification, and the modifications have not been made. He will thus refresh the page to see the new state of the data, and will redo his modifications, or decide they should not be made anymore given the new state.

两个用户同时修改一个实体，如果最后修改成功，那么无论修改是什么，这是一个问题吗?如果有问题，请使用乐观锁定，并在出现问题时通知您的用户.没有办法解决.

Is it a problem if two users modify an entity concurrently, and if the last modification wins, whatever the modification is? If it is a problem, then use optimistic locking, and inform your user when there is a problem. There's no way around it.

如果这不是问题，请不要使用乐观锁定.最后的修改(如果它没有破坏数据库中的约束)将始终获胜.但是让并发用户修改同一数据将总是会导致异常(例如，因为某些用户可能在其他用户向同一实体提交修改之前删除该实体).

If it's not a problem, then don't use optimistic locking. The last modification, if it doesn't break constraints in your database, will always win. But having concurrent users modifying the same data will always lead to exceptions (for example, because some user might delete an entity before some other user submits a modification to the same entity).

无法重试:

• 这两种方法都会再次失败，因为无法进行修改
• 否则它会成功，但首先会挫败乐观锁定的观点.

您的问题可以用汽车类比来解释.假设您选择购买带有限速器的汽车，以确保您不违反限速规定.现在您问:但是我不在乎速度限制.我不应该总是禁用速度限制器吗?您可以，但是如果您被警察抓住，那就不要感到惊讶.

Your problem could be explained with a car analogy. Suppose you choose to buy a car with a speed limiter, in order to make sure you don't break the speed limit. And now you ask: but I don't care about the speed limits. Shouldn't I always disable the speed limiter? You can, but then don't be surprised if you get caught by the police.

这篇关于如何处理锁(JPA)?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！