Транзакционный: Каждый раз, когда вы добавляете аннотацию @Transactional, он активирует транзакционное поведение, которое квалифицирует свойства ACID
ACID: ACID ( Atomicity , Согласованность , Изоляция , Долговечность ) - это набор свойств транзакций базы данных, предназначенных для гарантии достоверности даже в случае ошибок.
Атомная Гарантирует, что все операции в транзакции рассматриваются как одна «единица», которая либо завершается успешно, либо завершается неудачей.
Последовательный Гарантирует, что транзакция может перевести базу данных только из одного допустимого состояния в другое, предотвращая повреждение данных.
Изоляция Определяет, как и когда изменения, сделанные одной транзакцией, становятся видимыми для другой. Serializable и Snapshot Isolation - это два верхних уровня изоляции с точки зрения строгости.
Durable Гарантирует, что результаты транзакции постоянно хранятся в системе. Изменения должны сохраняться даже в случае отключения питания или сбоя системы.
Lock: Не следует путать с транзакцией, @ Lock включает поведение блокировки во время транзакции
В JPA определены два основных типа блокировки.
- Пессимистическая блокировка
- Оптимистическая блокировка
Если вы хотите узнать больше о пессимистической и обтимистической блокировках, вы можете изучить Интернет, ниже приведено объяснение от Baeldung ,
Пессимистическая блокировка Когда мыиспользуя пессимистическую блокировку в транзакции и доступ к объекту, она будет немедленно заблокирована. Транзакция снимает блокировку, совершая или откатывая транзакцию.
Оптимистическая блокировка В Оптимистической блокировке транзакция не блокирует сущность немедленно. Вместо этого транзакция обычно сохраняет состояние объекта с назначенным ему номером версии.
Когда мы пытаемся обновить состояние объекта в другой транзакции, транзакция сравнивает сохраненный номер версии с существующим номером версии в течениеupdate.
На этом этапе, если номер версии отличается, это означает, что объект не может быть изменен. Если есть активная транзакция, то эта транзакция будет откатана, и базовая реализация JPA сгенерирует исключение OptimisticLockException.
Помимо подхода с номером версии, мы можем использовать другие подходы, такие как отметки времени, вычисление значения хеш-функции илиСериализованная контрольная сумма, в зависимости от того, какой подход является наиболее подходящим для нашего текущего контекста разработки.
Есть также другие типы блокировки, доступные весной
- НЕТ: Без блокировки.
- ОПТИМИСТИЧЕСКИЙ: Оптимистическая блокировка.
- OPTIMISTIC_FORCE_INCREMENT: Оптимистическая блокировка, с обновлением версии.
- PESSIMISTIC_FORCE_INCREMENT: Пессимистическая блокировка записи, с обновлением версии
- PESSIMISTIC_READ: Пессимистическая блокировка чтения.
- PESSIMISTIC_WRITE: Пессимистическая блокировка записи.
- READ: Синоним OPTIMISTIC.
- WRITE: Синонимс OPTIMISTIC_FORCE_INCREMENT.
Теперь ответьте на свои вопросы
- Каковы основные различия / отношения в этих двух аннотациях?
Вы поймете после прочтения выше
Когда использовать @Transactional и когда использовать @Lock?
Если вам нужно поведение транзакций, добавьте @transactional, и если ваш сценарий использования требует блокировки и в соответствии с вариантом использования используйте соответствующую блокировку
Полезно ли @Lock в системе распределенных баз данных для предоставления данныхактуальность и согласованность?
Двумя основными инструментами, которые мы используем для обеспечения параллелизма, являются транзакции базы данных и распределенные блокировки. Эти два не являются взаимозаменяемыми. Вы не можете использовать транзакцию, когда вам нужна блокировка. Вы не можете использовать блокировку, когда вам нужна транзакция. source