Spring Transaction Management Overview

Outline

The transaction was originally the concept of a database for data access layer. However, under normal circumstances, the transaction needs to be elevated to the business layer, namely Service layer. This is done to be able to use features to manage the affairs of the specific business.

Spring is usually in the management of affairs may be achieved through the following three ways:

Use Spring's transaction management proxy factory affairs (obsolete)
Annotation using Spring's transaction management services
Using the AspectJ AOP Configuration Management

Spring transaction management API

Spring's transaction management, transaction-related uses two main interfaces.

Transaction Manager Interface

Transaction Manager is PlatformTransactionManagerthe interface object. It is mainly used to submit the completion of the transaction, rollback, and obtain transaction status information.

This interface defines three methods affairs:

void commit(TransactionStatus status): Submit affairs
TransactionStatus getTransaction(TransactionDefinition definition): Get affairs of state
void rollback(TranscationStatus status): Roll back the transaction

Two common implementation class
PlatformTransactionManager interface has two common implementation class:

DataSourceTransactionManager: Use MyBatis using JDBC or persistent data.
HibernateTransactionManager: Use when using Hibernate for persistence data.

Spring rollback mode
the default mode Spring roll back the transaction are: abnormal rollback occurs when running

example:

Multiple exception types, an array:@Transactional(rollbackFor={IOException.class,FileNoteFoundException})
If you want to specify when the encounter is not rolled back several RuntimeException:@Transactional(noRollbackFor={NullPointerException.class,IndexOutOfBoundsException.class})

Transaction-defined interfaces

TransactionDefinition Affairs defines the interface defined in the relevant transaction described three types of constants: transaction isolation level (isolation), transaction propagation behavior (propagation), the default transaction timeout, and operations on them.

Four isolation level of the transaction

DEFAULT: DB uses the default transaction isolation level. MySql default REPEATABLE_READ; Oracle default: READ_COMMITTED;
READ_UNCOMMITTED: read uncommitted. Not solve any concurrency issues.
READ_COMMITTED: Read Committed. Solve dirty read, there is a non-repeatable read and phantom reads.
REPEATABLE_READ: Repeatable Read. Solve dirty reads, non-repeatable reads. The presence of phantom reads.
SERIALIZABLE: serialization. There is no concurrency issues.

Examples: property isolation
transaction isolation level is the concept of the database, when multiple transactions for a number of operating records, the possible values of the property situation conflicts may occur are:

Isolation.DEFAULT: Database default isolation level
Isolation.READ_UNCOMMITED: Read uncommitted. Other data can be read uncommitted transactions. Lead to dirty read (dirty read)
Isolation.READ_COMMITED: Read Committed. This is the default isolation level many databases, but not MySQL. Other data can not be read uncommitted transaction, you can only read data has been submitted. Solve the dirty reads that can lead to non-repeatable read and phantom read.
- Non-repeatable read: after the pre-reading, before the commit, other transactions update the data, leading to twice the read data is not the same
- Magic Reading: After the pre-read before the commit, insert other transaction data, resulting in twice the number of pieces of data read is not the same
Isolation.REPEATABLE_READ: Repeatable Read. This is the default MySQL transaction isolation level. Solved dirty reads, non-repeatable read, but remains phantom read problems.
Isolation.SERIALIZABLE: Serializable. The highest transaction isolation level. Solve the dirty read, non-repeatable read, phantom read, but lead to a lot of timeouts and lock contention.

Seven kinds of transaction propagation behavior of
the so-called transaction propagation behavior means that, in the case of maintenance methods different transactions at the time of each call, during the execution of the transaction. For example, a A method of transaction () method call transaction b B (), in the case of maintenance calls performed during the transaction, the transaction is called propagation behavior. Transaction propagation behavior is applied to the method.

REQUIRED: The specified method must execute within a transaction. If the current transaction exists, it is added to the current transaction; if no transaction, create a new business. This propagation behavior is the most common choice, but also the default Spring transaction propagation behavior.
SUPPORTS: specified method to support the current transaction, but if no transaction can be performed in a non-transactional way.
MANDATORY: specified method must be executed within the current transaction, if no transaction is a direct throw.
REQUIRES_NEW: always create a new transaction, if the current transaction exists, the current transaction will be suspended until a new transaction is finished.
NOT_SUPPORTED: specified method can not be executed in a transaction environment, if the current transaction exists, it will suspend the current transaction.
NEVER: specified method can not be executed in a transactional context, if the current transaction exists, direct throw an exception.
NESTED: The specified method must execute within a transaction. If the current transaction exists, it is executed within the nested transaction; if no transaction, create a new business.

Example: attribute propagation

A.f1 () there is a transaction A

B.f2 () there is a transaction B

When A.f1 () call B.f2 () is, B.f2 Code () is executed which transaction
may have the value of the property (up to understand the following attribute values in B.f2 ()):

Propagation.REQUIRED: If A.f1 () call B.f2 (), then B.f2 () A transaction executed in; if B.f2 () is not called, then the implementation of their own affairs B. To accept, to accept it, do not give it with their own.
Propagation.SUPPORTS: If B.f2 () is () call A.f1, then execution A transaction; if the method is invoked without a transaction, then execute without a transaction environment. To accept, to accept it, do not give and do not.
Propagation.MANDATORY: B.f2 () can not open their own affairs, can only be opened A.f1 transaction () call, if there is no other way to call the transaction open, then throw an exception. I did not give, must be given, not to cry.
Propagation.REQUIRES_NEW: If A.f1 () call B.f2 (), then the transaction A is suspended, re-create a transaction B, B.f2 () execute in a transaction B, B is finished before continuing execution A transaction. To accept, to not close, with their own.
Propagation.NOT_SUPPORTED: B.f2 () need not be performed in a transaction. A transaction is required if the A.f1 () call, then the transaction A is suspended, B.f2 () A finished before resuming. Do not accept, is not hard to collect.
Propagation.NEVER: B.f2 () can not be performed in any transaction, if A.f1 () call it, then throw an exception. Never accept, hard to desperately.

example:

`@Transactianal` Notes Some properties

// control transaction propagation. The default is Propagation.REQUIRED 
the @Transactional (propagation = Propagation.REQUIRED)   


// control transaction isolation level. The default isolation level with the same default database 
@Transactional (Isolation = Isolation.DEFAULT)         


// control transaction may read and write (read-write default) 
@Transactional (= readOnly to false ) 


// read only, thus saving the overhead of some resources 
@ of the transactional (readOnly = to true ) 


// control the transaction timeout in seconds. With the same default database transaction control system, said to be 30 seconds 
the @Transactional (timeout = 30 )         


// control transaction rollback which exceptions will encounter. The default is RuntimeException 
the @Transactional (rollbackFor = RuntimeException. Class ) 


// Ibid 
@Transactional (rollbackForClassName =RuntimeException) 


// control which exceptions will not roll back the transaction experience. Default encountered non RuntimeException does not roll back 
the @Transactional (noRollbackFor = NullPointerException. Class )    


// Ibid 
@Transactional (noRollbackForClassName = NullPointerException)

Note : @TransactionalIt should be added in a specific category instead of interfaces