Я действительно не уверен, когда дело доходит до блокировки весной jpa.
Поэтому, пожалуйста, рассмотрите этот вопрос как разъяснение. Я очень надеюсь, что понял это правильно, но мой английский не очень хорош для понимания сложных сообщений в блогах.
Так это то, что я думаю, что я получил от некоторых статей:Весна JPA Lock
Есть два основных типа блокировки:
- оптимизм следует использовать, когда менее операция записи не планируется. операция чтения не будет блокировать объект.
Например: у вас есть «денежный баланс», плавающий в объекте с оптимистичной блокировкой. Теперь два процесса читают это значение и используют его для вычисления и прочее. Один из них теперь изменяет значение и записывает его в базу данных с обновлением. Никакой ошибки до этого момента.
Но теперь другой процесс также изменяет значение и хочет его обновить. Теперь есть ошибка. Это произошло только из-за второго обновления.
Если бы второй процесс удалил экземпляр, ничего бы не получилось. - пессимистический следует использовать, когда планируется большая операция записи. операция чтения заблокирует объект.
Например: у вас есть «денежный баланс», плавающий в сущности с пессимистической блокировкой. Один процесс считывает данные/значение с помощью «findOne».
После этого другой процесс хочет также прочитать данные, что было бы возможно с оптимистичной блокировкой, но с пессимистичной блокировкой он должен теперь ждать (нет ошибки, просто подождите).
Когда процесс 1 готов (изменение значения и его обновление), процесс 2 может продолжаться.
Первые вопросы: это правильно? И когда я теперь хочу проверить эту knollage, я могу выбрать между этим LockModeType-х:
- ОПТИМИСТИЧЕСКАЯ
- OPTIMISTIC_FORCE_INCREMENT
- PESSIMISTIC_READ
- PESSIMISTIC_WRITE
- PESSIMISTIC_FORCE_INCREMENT
Почему там сейчас так много субблокировок и что они делают? Когда «ОПТИМИЗАЦИЯ» - это оптимистичная блокировка сверху, которую я пытался понять, то что такое «OPTIMISTIC_FORCE_INCEMENT»?
И что же касается обновления версии? (или @version?)
Отправляясь:
Есть три основных применения замка в Спринг JPA:
на обычной колонке, например:
@Entity public class PersonEntity { @Id @GeneratedValue(strategy = GenerationType.AUTO) private Long id; @Lock(LockModeType.PESSIMISTIC_WRITE) private String name; }на внешний ключ к другой таблицы, например:
@Entity public class PersonEntity { @Id @GeneratedValue(strategy = GenerationType.AUTO) private Long id; @Lock(LockModeType.PESSIMISTIC_WRITE) @OneToOne private Group group; }на столе внутри хранилища, например:
interface PersonRepository extends Repository<Person, Long> { @Lock(LockModeType.PESSIMISTIC_WRITE) Person findOne(Long id); }
Блокировка Entity непосредственно
@Entity
@Lock(LockModeType.PESSIMISTIC_WRITE)
public class PersonEntity { }
не представляется возможным. Поэтому вы можете использовать 3 (заблокировать внутри репозитория).
Второй вопрос: Это правильно? Я забыл об использовании блокировки?
Идея блокировки заключается в том, что другим методам/процессам приходится ждать, пока блокировка не будет выпущена (за исключением оптимистической блокировки, здесь возникает ошибка).
Блокировка существует до тех пор, пока экземпляр/объект активен или до следующего фиксации.
Существуют две основные возможности, чтобы разблокировать объект:
В транзакции: В этом методе полной блокировки активен. Но когда придет возврат, замок будет удален.
@Transactional public void test(){ System.out.println("start, but not locked yet"); PersonEntity person1 = personRepository.findOne(1L); // locks this person or must wait, when locked System.out.println("now locked"); // do something return true; // now the lock will be deleted -> unlocked again }до тех пор, пока объект не будет удален: Данные будут заблокированы при выборе объекта, и данные будут разблокированы, когда объект будет удален.
public void test(){ System.out.println("start, but not locked yet"); PersonEntity person1 = personRepository.findOne(1L); // locks this person or must wait, when locked System.out.println("now locked"); // do something person1 = null; // now the lock will be deleted -> unlocked again System.out.println("not locked anymore"); // do something more return true; }
Третьи Вопросы: правильно ли это до сих пор? Может ли эта функция действительно ждать, тогда данные заблокированы? Может ли замок действительно быть удален, если объект установлен на null?
Последние слова:
Я действительно надеюсь, что я никого не потревожу. Но, как я сказал, мне очень сложно понять такие сложные структуры на английском языке :(
Так что спасибо за помощь в любой форме :) Я очень ценю любую небольшую помощь. независимо от того, вы даете ссылки меня для большего понимания и отвечать на мои вопросы прямо :)
В двух словах, в типичных интерактивных приложениях, особенно в веб-приложениях, любая форма пессимистического замка редко требуется, и это не имеет смысла. 'OPTIMISTIC_FORCE_INCREMENT' необходим только тогда, когда вам нужно заблокировать весь объект, включая его содержащие объекты, что также случается довольно редко. В большинстве случаев вас беспокоит только '@ javax.persistence.Version'. – Tiny
Вы действительно попробовали какие-либо опции, чтобы подтвердить свое понимание? –
да, кроме разблокировки. – christopher2007