Разлика между LockModeType Jpa

Първо бих разграничил оптимистичните и песимистичните ключалки, тъй като те са различни в основния си механизъм.

Оптимистичното заключване е напълно контролирано от JPA и изисква само допълнителна колона версия в таблиците на DB. Той е напълно независим от базовата DB машина, използвана за съхраняване на релационни данни.

От друга страна, песимистичното заключване използва заключващ механизъм, предоставен от основната база данни, за да заключи съществуващи записи в таблици. JPA трябва да знае как да задейства тези заключвания и някои бази данни не ги поддържат или само частично.

Сега към списъка с типове заключване:

1. LockModeType.Optimistic
   • Ако обектите посочат поле за версия, това е по подразбиране. За обекти без колона версия, използването на този тип заключване не е гарантирано, че ще работи при която и да е реализация на JPA. Този режим обикновено се игнорира, както е посочено от ObjectDB. Според мен той съществува само за да можете да изчислявате динамично режима на заключване и да го предавате по-нататък, дори ако заключването в крайна сметка ще бъде ОПТИМИСТИЧНО. Въпреки това не е много вероятен случай на употреба, но винаги е добър дизайн на API, за да се осигури опция за препратка дори към стойността по подразбиране.

• Пример:

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

2. LockModeType.OPTIMISTIC_FORCE_INCREMENT

• Това е рядко използвана опция. Но може да е разумно, ако искате да заключите препращането към този обект от друг обект. С други думи, искате да заключите работата с обект, дори ако той не е променен, но други обекти могат да бъдат променени във връзка с този обект.
• Пример:Имаме обект книга и рафт. Възможно е да добавите книга към рафта, но книгата няма препратка към нейния рафт. Разумно е да се заключи действието на преместване на книга на рафт, така че книгата да не се окаже в друг рафт (поради друга транзакция) преди края на тази транзакция. За да заключите това действие, не е достатъчно да заключите текущия обект на лавицата за книги, тъй като книгата все още не трябва да е на рафт. Също така няма смисъл да заключвате всички целеви рафтове за книги, тъй като те вероятно биха били различни при различните транзакции. Единственото нещо, което има смисъл, е да заключите самата книжна единица, дори ако в нашия случай не се промени (той не съдържа препратка към лавицата за книги).

3. LockModeType.PESSIMISTIC_READ

• този режим е подобен на LockModeType.PESSIMISTIC_WRITE , но различни в едно нещо:докато не се установи заключване на запис на същия обект чрез някаква транзакция, то не трябва да блокира четенето на обекта. Също така позволява на други транзакции да се заключват с помощта на LockModeType.PESSIMISTIC_READ . Разликите между ключалките WRITE и READ са добре обяснени тук (ObjectDB) и тук (OpenJPA). Ако обект вече е заключен от друга транзакция, всеки опит за заключване ще доведе до изключение. Това поведение може да бъде променено така, че да изчака известно време за освобождаване на заключването, преди да хвърли изключение и да върне транзакцията обратно. За да направите това, посочете javax.persistence.lock.timeout намек с броя милисекунди за изчакване, преди да хвърли изключението. Има няколко начина да направите това на множество нива, както е описано в урока за Java EE.

4. LockModeType.PESSIMISTIC_WRITE

• това е по-силна версия на LockModeType.PESSIMISTIC_READ . Когато WRITE заключването е на място, JPA с помощта на базата данни ще попречи на всяка друга транзакция да чете обекта, а не само да пише както с READ заключване.
• Начинът, по който това се прилага в доставчик на JPA в сътрудничество с основната DB, не е предписан. Във вашия случай с Oracle бих казал, че Oracle не предоставя нещо близко до READ ключалка. SELECT...FOR UPDATE наистина е по-скоро WRITE ключалка. Може да е грешка в хибернация или просто решение, което вместо да внедрява персонализирано "по-меко" READ заключване, "по-трудното" WRITE вместо това се използва заключване. Това най-вече не нарушава последователността, но не поддържа всички правила с READ ключалки. Можете да изпълните някои прости тестове с READ заключвания и продължителни транзакции, за да разберете дали повече транзакции могат да получат READ заключва на същия обект. Това трябва да е възможно, докато не с WRITE ключалки.

5. LockModeType.PESSIMISTIC_FORCE_INCREMENT

• това е друг рядко използван режим на заключване. Въпреки това, това е опция, при която трябва да комбинирате PESSIMISTIC и OPTIMISTIC механизми. Използване на обикновен PESSIMISTIC_WRITE ще се провали при следния сценарий:
  1. транзакция A използва оптимистично заключване и чете обект E
  2. транзакция B придобива заключване на WRITE на обект E
  3. транзакция B извършва и освобождава заключването на E
  4. транзакция A актуализира E и извършва ангажименти
• в стъпка 4, ако колоната версия не се увеличава с транзакция B, нищо не пречи на A да презапише промените на B. Режим на заключване LockModeType.PESSIMISTIC_FORCE_INCREMENT ще принуди транзакция B да актуализира номера на версията и ще доведе до неуспех на транзакция A с OptimisticLockException , въпреки че B използваше песимистично заключване.

6. LockModeType.NONE

• това е по подразбиране, ако обектите не предоставят поле за версия. Това означава, че не е активирано заключване, конфликтите ще бъдат разрешени на базата на най-доброто усилие и няма да бъдат открити. Това е единственият разрешен режим на заключване извън транзакция