JPA：读取锁是如何工作的？
我试图了解调用EntityManager.lock（entity，LockModeType.READ）的效果。API 文档对我来说听起来很混乱。
如果我必须并发线程，线程1调用lock（实体，LockModeType.READ），线程2还能读写实体吗？
到目前为止，我学到了什么：
JPA1 中的锁类型 READ 与 JPA2 中的 OPTIMISTIC 相同。如果设置了此类锁，则实体管理器会在提交事务之前检查版本属性，但不会更新它。我找到了乐观锁定模式的解释：链接。搜索乐观（读取）锁定模式示例。据我了解，在线程 1 中设置读锁定对线程 2 没有影响......n.所有其他线程仍然可以读取和写入实体。但是，当线程 1 中的事务提交并且另一个线程更新了实体时，线程 1 中的事务将回滚。
我的理解正确吗？
共有1个答案
阅读无论如何都是被弃用的，但只是为了你的理解：
READ锁将确保对象的状态在提交时不会改变，因为READ锁允许其他事务更新或删除它，然后如果线程1做了一些改变，然后提交它，首先检查实体的状态（版本），如果检查，则提交，如果不允许，则不允许，
所以基本上你的理解是正确的。
还有OPTIMISTIC_READ，这是使用它的现代方式（还有_WRITE）。
更新
好的，这篇文章对我理解有很大帮助，希望这有帮助。
-
我读过一些关于意图锁的文章，其中有很多意图锁，它们是意图共享(IS)、意图独占(IX)、与意图独占共享(SIX)、意图更新(IU)、共享意图更新(SIU)、更新意图独占(UIX)。有时我在锁统计信息中发现了这些锁，但我很难识别这些锁中的每一个，因为有时会发生许多性能问题
-
在我加入的新项目中，他们一直交替使用术语Hibernate和JPA。所以，我试图深入研究代码并试图理解整个事情是如何工作的（我是Spring、JPA和Hibernate世界的新手）。我将尝试将代码放在这里以更好地理解：1）有一个@Configuration类，其中有以下内容： 因此，在这个配置类中，我们返回一个EntityManagerFactory。 2） 然后是一个标记为@persistor的
-
我正在学习Java中的同步。我无法理解倒计时锁的确切机制。 CountDownLatch是否根据声明中给出的线程数“倒数锁存器”（等待线程数完成）？ 这是我试图理解的代码： 在上面的例子中： ExecutorService（从线程池）生成7个线程。我的理解是闩锁应该等待6个线程（从0到5）的完成，定义如下： 但我得到的输出并不是每次都是恒定的。有时会等待6个线程完成，有时会等待7个线程完成，例如：
-
应用程序具有上下文路径-->/spring-form-simple-project 因此，为了访问，我使用： 这个控制器又返回student.jsp，当提交这个student.jsp时，它用-->@RequestMapping(value=“/AddStudent”,method=RequestMethod.post）调用controller 任何关于这通常如何工作的指示都将是有帮助的。 谢谢！
-
问题内容： 假设我有一个名为取款的表（id，金额，user_id，状态）。 每当我开始提款时，流程如下： 验证用户是否有足够的余额（按收到的金额之和-取款金额之和计算） 插入行，其金额为user_id，status =``结束’‘。 通过gRPC调用第三方软件以发起提款（实际上是汇款），等待响应 如果我们收到肯定的答复，请立即更新状态为“已完成”的行；如果提款失败，则删除该条目。 但是，我在此流程
-
我有点困惑，试图确定如何窥视锁的工作在服务总线。特别是，我使用Microsoft.Azure.ServiceBus和Azure函数以及ServiceBustrigger。 据我所知，消息被锁定的时间设置在队列本身上，默认值为30秒，但也可以设置在任何地方，最多为5分钟。 当从队列中窥视到一条消息时，这个锁就会启动。 我还有的问题是 是否存在maxAutoRenewDuration可以设置的限制。我