LockModeType Jpa之间的区别 [英] Difference between LockModeType Jpa

问题描述

我对JPA中LockModeTypes的工作感到困惑：

1. LockModeType.Optimistic

   
   
   
   
   
   • 它会在提交时递增版本。
   
   
   • 我在我的实体中有版本列，如果我不指定这种锁定模式，那么它的工作原理类似于它的用途是什么？
   
   



2. LockModeType.OPTIMISTIC_FORCE_INCREMENT

   
   
   
   
   
   • 即使实体未更新。
   
   
   • 但是，如果任何其他进程在此事务提交之前更新了同一行，它的用途是什么？这个事务无论如何都会失败。那么这个 LockModeType 的用法是什么。
   
   



3. LockModeType.PESSIMISTIC_READ

   
   
   
   
   
   • 此锁定模式发出 nowait （如果没有指定hint超时）..
   
   
   • 所以基本上这意味着没有其他事务可以更新这行，直到这个事务提交，写锁，为什么它命名为读锁定
   
   



4. code> LockModeType.PESSIMISTIC_WRITE

   
   
   
   
   
   • 此锁定模式也会发出 select对于更新nowait （如果没有指定提示超时）。
   
   
   • 问题这里是什么是锁模式和之间的区别LockModeType.PESSIMISTIC_READ 因为我看到两个火情相同的查询？
   
   



5. LockModeType.PESSIMISTIC_FORCE_INCREMENT

   
   
   
   
   
   • 这样做选择更新nowait 没有提示超时指定），也增加版本号。
   
   
   • 我完全没有使用它。
   
   
   • 如果用于更新无等待，是否需要
   
   




>乐观锁定完全由JPA控制，并且只需要DB表中的附加版本列。它完全独立于用于存储关系数据的底层数据库引擎。

另一方面，悲观锁使用底层数据库提供的锁定机制来锁定表中的现有记录。 JPA需要知道如何触发这些锁，一些数据库不支持它们或仅部分。

现在到锁定类型列表：

1. LockModeType.Optimistic

   
   
   
   
   
   • 这是真的默认值。通常会被 ObjectDB 忽略。在我看来，它只存在，所以你可以计算锁定模式动态和传递，即使锁将是OPTIMISTIC到底。
   
   

   • 示例：

     
     
     

     LockModeType lockMode = resolveLockMode（）;
A a = em.find（A.class，1，lockMode）;

   
   



2. LockModeType.OPTIMISTIC_FORCE_INCREMENT

   
   
   
   
   
   • 选项。但是，如果您想要锁定由另一个实体引用此实体，这可能是合理的。换句话说，即使未修改实体，您也希望锁定与实体的工作，但其他实体可能会根据实体进行修改。
   
   
   • 示例：我们有实体Book和Shelf。可以添加书到书架，但书没有任何参考它的书架。锁定将书移动到书架上的动作是合理的，使得书在该交易结束之前不会结束在另一书架中（由于另一交易）。要锁定此操作，锁定当前书架实体是不够的，因为该书不必在书架上。锁定所有目标书架也没有意义，因为它们在不同的事务中可能不同。唯一有意义的是锁定图书实体本身，即使在我们的情况下它不会改变（它不会引用其书架）。
   
   



3. LockModeType.PESSIMISTIC_READ

   
   
   
   
   
   • 模式类似于 LockModeType.PESSIMISTIC_WRITE ，但在一件事上不同：直到写锁在一些事务在同一个实体上就位，它不应该阻塞读取实体。它还允许使用 LockModeType.PESSIMISTIC_READ 锁定其他事务。 WRITE和READ锁定之间的差异在这里（ObjectDB）和 here（OpenJPA）。
   
   



4. LockModeType.PESSIMISTIC_WRITE

   
   
   
   
   
   • 这是 LockModeType.PESSIMISTIC_READ 的更强版本。当 WRITE 锁定到位时，JPA在数据库的帮助下将阻止任何其他事务读取实体，而不仅仅是使用 READ 锁定。
   
   
   • 没有规定JPA提供者与底层DB合作实现此方法的方式。在Oracle的情况下，我会说Oracle不提供接近 READ 的锁。 SELECT ... FOR UPDATE 真的是一个 WRITE 锁。这可能是hibernate中的一个错误，或者只是一个决定，而不是实现自定义的更软的 READ 锁，更难的 WRITE lock。这大多不会破坏一致性，但不能保持所有规则与 READ 锁。您可以使用 READ 锁和长时间运行的事务运行一些简单的测试，以了解更多事务是否能够获取 READ 锁定在同一个实体上。这应该是可能的，而不是 WRITE 锁。
   
   



5. LockModeType.PESSIMISTIC_FORCE_INCREMENT

   
   
   
   
   
   • 这是另一种很少使用的锁定模式。但是，它是一个选项，您需要结合 PESSIMISTIC 和 OPTIMISTIC 机制。在以下情况下使用纯$ PESSIMISTIC_WRITE 将失败：
     
     
     
     
     1. 事务A使用乐观锁定并读取实体E
     
     
     2. 事务B获取实体E上的WRITE锁定
     
     
     3. 事务B提交并释放E的锁定
     
     
     4. 事务A在步骤4中更新E并提交
     
     

   
   
   • ，如果版本列未被事务B递增，则无法阻止A覆盖B的更改。锁定模式 LockModeType.PESSIMISTIC_FORCE_INCREMENT 将强制事务B更新版本号，并导致事务A失败， OptimisticLockException B使用悲观锁定。
   
   

I am confused about the working of LockModeTypes in JPA:

1. LockModeType.Optimistic

   • it increments the version while committing.
   • Question here is : If I have version column in my entity and if I don't specify this lock mode then also it works similarly then what is the use of it?

2. LockModeType.OPTIMISTIC_FORCE_INCREMENT

   • Here it increments the version column even though the entity is not updated.
   • but what is the use of it if any other process updated the same row before this transaction is committed? this transaction is anyways going to fail. so what is the use of this LockModeType.

3. LockModeType.PESSIMISTIC_READ

   • This lock mode issues a select for update nowait(if no hint timeout specified)..
   • so basically this means that no other transaction can update this row until this transaction is committed, then its basically a write lock, why its named a Read lock?

4. LockModeType.PESSIMISTIC_WRITE

   • This lock mode also issues a select for update nowait (if no hint timeout specified).
   • Question here is what is the difference between this lock mode and LockModeType.PESSIMISTIC_READ as I see both fires same queries?

5. LockModeType.PESSIMISTIC_FORCE_INCREMENT

   • this does select for update nowait (if no hint timeout specified) and also increments the version number.
   • I totally didn't get the use of it.
   • why a version increment is required if for update no wait is there?

解决方案

I would first differentiate between optimistic and pessimistic locks, because they are different in their underlying mechanism.

Optimistic locking is fully controlled by JPA and only requires additional version column in DB tables. It is completely independent of underlying DB engine used to store relational data.

On the other hand, pessimistic locking uses locking mechanism provided by underlying database to lock existing records in tables. JPA needs to know how to trigger these locks and some databases do not support them or only partially.

Now to the list of lock types:

1. LockModeType.Optimistic

   • This is really the default. It is usually ignored as stated by ObjectDB. In my opinion it only exists so that you may compute lock mode dynamically and pass it further even if the lock would be OPTIMISTIC in the end. Not very probable usecase though, but it is always good API design to provide an option to reference even the default value.

   • Example:

     LockModeType lockMode = resolveLockMode(); A a = em.find(A.class, 1, lockMode);

2. LockModeType.OPTIMISTIC_FORCE_INCREMENT

   • This is a rarely used option. But it could be reasonable, if you want to lock referencing this entity by another entity. In other words you want to lock working with an entity even if it is not modified, but other entities may be modified in relation to this entity.
   • Example: We have entity Book and Shelf. It is possible to add Book to Shelf, but book does not have any reference to its shelf. It is reasonable to lock the action of moving a book to a shelf, so that a book does not end up in another shelf (due to another transaction) before end of this transaction. To lock this action, it is not sufficient to lock current book shelf entity, as the book does not have to be on a shelf yet. It also does not make sense to lock all target bookshelves, as they would be probably different in different transactions. The only thing that makes sense is to lock the book entity itself, even if in our case it does not get changed (it does not hold reference to its bookshelf).

3. LockModeType.PESSIMISTIC_READ

   • this mode is similar to LockModeType.PESSIMISTIC_WRITE, but different in one thing: until write lock is in place on the same entity by some transaction, it should not block reading the entity. It also allows other transactions to lock using LockModeType.PESSIMISTIC_READ. The differences between WRITE and READ locks are well explained here (ObjectDB) and here (OpenJPA).

4. LockModeType.PESSIMISTIC_WRITE

   • this is a stronger version of LockModeType.PESSIMISTIC_READ. When WRITE lock is in place, JPA with the help of the database will prevent any other transaction to read the entity, not only to write as with READ lock.
   • The way how this is implemented ina JPA provider in cooperation with underlying DB is not prescribed. In your case with Oracle, I would say that Oracle does not provide something close to a READ lock. SELECT...FOR UPDATE is really rather a WRITE lock. It may be a bug in hibernate or just a decision that, instead of implementing custom "softer" READ lock, the "harder" WRITE lock is used instead. This mostly does not break consistency, but does not hold all rules with READ locks. You could run some simple tests with READ locks and long running transactions to find out if more transactions are able to acquire READ locks on the same entity. This should be possible, whereas not with WRITE locks.

5. LockModeType.PESSIMISTIC_FORCE_INCREMENT

   • this is another rarely used lock mode. However, it is an option where you need to combine PESSIMISTIC and OPTIMISTIC mechanisms. Using plain PESSIMISTIC_WRITE would fail in following scenario:
     1. transaction A uses optimistic locking and reads entity E
     2. transaction B acquires WRITE lock on entity E
     3. transaction B commits and releases lock of E
     4. transaction A updates E and commits

   • in step 4, if version column is not incremented by transaction B, nothing prevents A from overwriting changes of B. Lock mode LockModeType.PESSIMISTIC_FORCE_INCREMENT will force transaction B to update version number and causing transaction A to fail with OptimisticLockException, even though B was using pessimistic locking.

这篇关于LockModeType Jpa之间的区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！