Обзор
Управление транзакциями имеет решающее значение для корпоративных приложений, и оно может обеспечить согласованность данных, даже если возникают аномальные ситуации.
Spring Framework обеспечивает постоянную абстракцию для управления транзакциями, с его характеристиками следующим образом:
Предоставьте постоянные модели программирования для различных API транзакций, таких как JTA (Java Transaction API), JDBC, Hibernate, JPA (Java Persistence API и JDO (объекты данных Java)
Поддерживает декларативное управление транзакциями, особенно декларативное управление транзакциями на основе аннотаций, которое является простым и простым в использовании
Предоставляет API более простого API управления транзакциями программирования, чем другие API транзакции, такие как JTA
Идеальная интеграция с абстракцией доступа к данным Spring
Метод управления транзакциями
Spring поддерживает два метода: управление программными транзакциями и декларативное управление транзакциями.
Управление программными транзакциями использует TransactionTemplate или непосредственно использует базовую платформу ThransactionManager. Для управления программными транзакциями Spring рекомендует использовать TransactionTemplate.
Управление декларативными транзакциями построено на AOP. Его сущность состоит в том, чтобы перехватить метод до и после, а затем создать или добавить транзакцию до начала целевого метода. После выполнения целевого метода транзакция отправляется или откатается в соответствии с ситуацией выполнения. Самым большим преимуществом декларативных транзакций является то, что им не нужно программно управлять транзакциями, поэтому нет необходимости в коде управления транзакциями в коде бизнес -логики. Просто сделайте соответствующие объявления правил транзакции в файле конфигурации (или посредством аннотации @Transactional), и вы можете применить правила транзакции к бизнес -логике.
Очевидно, что декларативное управление транзакциями лучше, чем управление программными транзакциями, что является именно неинвазивным методом разработки, поддерживаемого Spring. Декларативное управление транзакциями не позволяет бизнес -коду без загрязнения. Нормальный объект POJO может получить полную поддержку транзакций, добавив аннотации. По сравнению с программирующими транзакциями, единственным недостатком декларативных транзакций является то, что лучшая гранулярность последнего может действовать только на уровне метода и не может быть достигнута, поскольку программная транзакция может действовать на уровне блока кода. Однако даже при таком требовании есть много обходных путей, таких как кодовые блоки, которые требуют управления транзакциями, могут быть независимо обработаны и т. Д.
Существует также два часто используемых метода для управления декларативными транзакциями. Один из них - файл конфигурации XML на основе пространств имен TX и AOP, а другой - Annotation @Transactional. Очевидно, что метод на основе аннотаций проще и проще в использовании и более освежает.
Автоматический коммит (AutoCommit) и автоматически отправлять при закрытии соединения соединение
Автоматическое представление
По умолчанию база данных находится в режиме автоматического представления. Каждое утверждение находится в отдельной транзакции. Когда выполнение этого оператора завершено, если выполнение будет успешным, транзакция неявно представлена.
Если выполнение не удается, транзакция неявно откатывается назад.
Для нормального управления транзакциями набор связанных операций находится в транзакции, поэтому автоматический режим коммита базы данных должен быть отключен. Тем не менее, нам не нужно беспокоиться об этом, Spring установит функцию автоматического коммита базового соединения с False.
org/springframework/jdbc/dataSource/dataSourcetransactionManager.java
// Переключитесь на ручной коммит, если это необходимо. Это очень дорого у некоторых драйверов JDBC, // поэтому мы не хотим делать это без необходимости (например, если мы явно // сконфигурировали пул соединений, чтобы установить его уже) .if (con.getAutocommit ()) {txobject.setmustrestoreautocommit (true); if (logger.isdebugenabled ()) {logger.debug ("Переключение соединения JDBC [" + con + "] на ручный коммит"); } con.setautocommit (false);}Некоторые пулы соединений для передачи данных предоставляют настройки для отключения автоматических транзакций, которые лучше всего отключить при настройке пула соединений. Тем не менее, C3P0 не предоставляет эту функцию и может полагаться только на пружину, чтобы установить ее.
Поскольку спецификация JDBC предусматривает, что, когда объект соединения установлен, он должен находиться в режиме автоматического коммита, который является значением по умолчанию в СУБД, а автоматический коммит должен быть явно отключен, если это необходимо. C3P0 соблюдает эту спецификацию и позволяет клиентскому коду явно устанавливать необходимый режим отправки.
Следует ли отправлять автоматически при закрытии соединения
Когда соединение закрыто, что следует обрабатывать, если есть незафиксированная транзакция? В спецификации JDBC не упоминается, что политика по умолчанию C3P0 заключается в отказе от любых незавершенных транзакций. Это правильная стратегия, но в этом вопросе нет согласия среди поставщиков драйверов JDBC.
Свойство AutoCommitonClose в C3P0 по умолчанию является ложным, поэтому нет необходимости не перемещать его. Или вы можете явно установить это свойство на False, что будет более ясным.
Конфигурация декларативной транзакции на основе аннотаций
Spring-servlet.xml
<!-Поддержка транзакций-> <!-PlatformTransactionMnager-> <bean id = "txmanager"> <name = "dataSource" ref = "dataSource" /> < /bean> <!-включить поддержку аннотации транзакции-> <TX: Annotation Transaction-Manager = "txmanager" />
Также добавьте пространство имен TX в Spring-servlet.xml
... xmlns: tx = "http://www.springframework.org/schema/tx" xmlns: aop = "http://www.springframework.org/schema/aop" xsi: schemalocation = "... //wwww.springfrema. http://www.springframework.org/schema/tx/spring-tx.xsd ...
Mybatis автоматически участвует в управлении транзакциями Spring без дополнительной конфигурации. Пока источник данных, на который ссылаются org.mybatis.spring.sqlsessionFactoryBean, согласуется с источником данных, на который ссылается DataSourcETransActionManager, в противном случае управление транзакциями не будет работать.
Кроме того, вам необходимо загрузить пакет зависимости aopalliance.jar и поместить его в каталог Web-Inf/Lib. В противном случае, когда инициализируется исключение, исключение будет сообщено
java.lang.noclassdeffounderror: org/aopalliance/urpectept/methodinterceptor
Весенние функции транзакции
Все классы политики управления транзакциями весной унаследованы от org.springframework.transaction.platformtransactionManager Интерфейс
Public Interface PlatformTransactionManager {TransactionStatus getTransaction (определение транзакции) Throws TransactionException; void Commit (TransactionStatus Status) Throws TransactionException; void hollback (статус TransactionStatus) Throws TransactionException;}Интерфейс TransactionDefinition определяет следующие характеристики:
Уровень изоляции транзакций
Уровень изоляции относится к степени изоляции между несколькими параллельными транзакциями. Пять констант, представляющих уровни изоляции, определены в интерфейсе TransactionDefinition:
TransactionDefinition.isolation_Default: это значение по умолчанию, указывающее уровень выделения по умолчанию, используемый для базовой базы данных. Для большинства баз данных это значение обычно является TransactionDefinition.isolation_read_committed.
TransactionDefinition.Isolation_Read_uncommitted: этот уровень изоляции указывает на то, что одна транзакция может считывать данные, измененные другой транзакцией, но еще не был совершен. Этот уровень не предотвращает грязное чтение, повторяющееся чтение и фантомное чтение, поэтому этот уровень изоляции редко используется. Например, PostgreSQL на самом деле не имеет этого уровня.
TransactionDefinition.Isolation_Read_Committed: этот уровень изоляции означает, что одна транзакция может считывать только данные, которые были совершены другой транзакцией. Этот уровень предотвращает грязное чтение, которое также является рекомендуемой ценностью в большинстве случаев.
TransactionDefinition.isolation_Repeatable_read: этот уровень изоляции указывает, что транзакция может выполнять запрос несколько раз на протяжении всего процесса, а возвращаемые записи одинаковы каждый раз. Этот уровень предотвращает грязные и незадачные показания.
TransactionDefinition.Isolation_Serializable: все транзакции выполняются один за другим в последовательности, так что нет возможности помех между транзакциями, то есть этот уровень может предотвратить грязное чтение, неподжие считываемости и фантомное чтение. Но это серьезно повлияет на производительность программы. Этот уровень обычно не используется.
Поведение коммуникации транзакций
Так называемое поведение распространения транзакций относится к тому, что если контекст транзакции уже существует до начала текущей транзакции, существует несколько вариантов, которые могут указать поведение выполнения транзакционного метода. Определение транзакции включает в себя следующие константы, представляющие поведение распространения:
TransactionDefinition.Propagation_Required: Если в настоящее время присутствует транзакция, присоединяйтесь к транзакции; Если в настоящее время нет транзакции, создайте новую транзакцию. Это значение по умолчанию.
TransactionDefinition.Propagation_Requires_New: создает новую транзакцию, и если транзакция в настоящее время существует, текущая транзакция будет приостановлена.
TransactionDefinition.Propagation_Supports: присоединяйтесь к транзакции, если в настоящее время есть транзакция; Если в настоящее время нет транзакции, она продолжает работать не транзакционным способом.
TransactionDefinition.Propagation_NOT_SUPPORTED: работает не транзакционным образом, и если в настоящее время существует транзакция, текущая транзакция будет приостановлена.
TransactionDefinition.Propagation_Never: работает не транзакционным способом, бросает исключение, если в настоящее время присутствует транзакция.
TransactionDefinition.Propagation_Mandatory: присоединяйтесь к транзакции, если в настоящее время есть транзакция; Если в настоящее время нет транзакции, исключение брошено.
TransactionDefinition.Propagation_Nestest: Если в настоящее время присутствует транзакция, транзакция создается для выполнения вложенной транзакции текущей транзакции; Если транзакция нет, значение эквивалентно транзакции definition.propagation_required.
Тайм -аут транзакции
Так называемый тайм-аут транзакции относится к максимальному времени, разрешенному транзакцией. Если ограничение по времени превышено, но транзакция не была завершена, транзакция будет автоматически откатана. В TransactionDefinition тайм -аут представлен значением Int, а его единица составляет секунды.
Настройка по умолчанию - это значение тайм -аута базовой системы транзакций. Если базовая система транзакций базы данных не устанавливает значение тайм -аута, то это нет, и нет ограничения тайм -аута.
Транзакция только для чтения атрибутов
Транзакции только для чтения используются в ситуациях, когда клиент-код только для чтения, но не изменяет данные. Транзакции только для чтения используются в оптимизации в определенных сценариях, например, при использовании Hibernate.
По умолчанию прочитано и записывает транзакции.
Правила обмолки с пружинной транзакцией
Рекомендуемый способ обучения менеджера Transaction Transaction для отказа от транзакции - это бросить исключение в контексте текущей транзакции. Менеджер по транзакциям Spring ловит любые нездоровые исключения, а затем решает, следует ли откатить транзакцию, которая бросает исключение на основе правил.
По умолчанию Spring откатится обратно транзакции только в том случае, если исключение является неконтролируемым исключением времени выполнения, то есть исключением является подкласс Runtimeexception (ошибки также приведут к откату от транзакции), в то время как выброс проверенного исключения не вызовет откат транзакции.
Можно явно настроить транзакцию для отката, когда эти исключения брошены, включая проверенные исключения. Также можно четко определить те транзакции, которые не откатываются, когда исключения брошены.
Вы также можете программно использовать метод setrollbackonly (), чтобы указать, что транзакция должна быть отката. Единственное, что вы можете сделать после вызова Setrollbackonly (), - это откат.
@Transactional Annotation
@Transactional Properties
| свойство | тип | описывать |
|---|---|---|
| ценить | Нить | Дополнительный дескриптор квалификатора, указавший диспетчер транзакций для использования |
| распространение | enum: распространение | Необязательные настройки поведения распространения транзакций |
| изоляция | enum: изоляция | Необязательные настройки уровня изоляции транзакций |
| Ридонли | логический | Читать и записать или транзакцию только для чтения, чтение и запись по умолчанию |
| тайм -аут | int (в секундах гранулярность) | Настройка тайм -аута транзакции |
| Откат | Массив объектов класса должен быть унаследован от броска | Массив классов исключений, которые вызывают откат транзакции |
| RollbackforClassName | Массив имен классов должен быть унаследован от броски | Массив имен классов исключений, которые вызывают откат транзакции |
| Norollbackfor | Массив объектов класса должен быть унаследован от броска | Массив классов исключений, который не вызывает откат транзакции |
| NorollbackforClassName | Массив имен классов должен быть унаследован от броски | Массив имен классов исключений, которые не вызовут откат транзакции |
Использование
@Transactional может действовать на интерфейсы, методы интерфейса, классы и методы класса. При выходе на класс все публичные методы класса будут иметь транзакционные свойства такого типа. В то же время мы также можем использовать эту аннотацию на уровне метода, чтобы переопределить определение уровня класса.
Хотя аннотация @Transactional может быть применена к интерфейсам, методам интерфейса, классам и методам класса, Spring рекомендует не использовать эту аннотацию на интерфейсах или методах интерфейса, потому что это вступает в силу только при использовании прокси на основе интерфейса. Кроме того, аннотация @Transactional должна применяться только к публичному методу, который определяется природой пружинного AOP. Если вы используете аннотацию @Transactional по защищенным, частным или по умолчанию методов видимости, это будет проигнорировано, и никаких исключений не будет брошено.
По умолчанию только вызовы методов извне будут захвачены прокси -сервером AOP, то есть вызов другим методам внутри этого класса внутри класса не вызовет поведение транзакций, даже если вызываемый метод изменяется с использованием аннотации @Transactional.
@TransActional (readonly = true) открытый класс по умолчанию). Реализации FooService {public foo getfoo (String fooname) {// Делать что -то} // Эти настройки имеют приоритет для этого метода // атрибут аннотации на методе переопределяют один и тот же атрибут на класс Annotation @TransActionAl (redateRyly = false, propagation = rovagation vorsire UpdateFoo (foo foo) {// что -то сделать}}Суммировать
Вышеуказанное - все содержание интерпретации этой статьи об использовании @Transactional Annotation весной, и я надеюсь, что это будет полезно для всех. Заинтересованные друзья могут продолжать ссылаться на другие связанные темы на этом сайте. Если есть какие -либо недостатки, пожалуйста, оставьте сообщение, чтобы указать это. Спасибо, друзья, за вашу поддержку на этом сайте!