The JavaEE system is developed in layers, and transaction processing is located in the business layer. Spring provides a layered design business layer transaction processing solution.
The Spring framework provides us with a set of transaction control interfaces.
Spring's transaction control is based on AOP, which can be implemented either programmatically or configurationally.
API Introduction
PlatformTransactionManager
This interface is spring's transaction manager, which provides common operation transaction methods, including 3 specific operations:
- Get transaction status information
- TransactionStatus getTransaction(TransactionDefinition definition)
- Commit transaction
- void commit(TransactionStatus status)
- Roll back the transaction
- void rollback(TransactionStatus status)
Objects that really manage transactions
org.springframework.jdbc.datasourec.DataSourceTransactionManager use Spring JDBC or iBatis for persistent data use
org.springframework.orm.hibernate5.HibernateTransactionManager use Hibernate version for persistent data
TransactionDefinition
It is a transaction definition information object, method:
- String getName () Get transaction object name
- int getIsolationLevel () Get transaction isolation level
- int getPropatationBehavior () Get transaction propagation behavior
- int getTimeout () Get transaction timeout
- boolean isReadOnly () Get whether the transaction is read-only. Read-
write transaction: add, delete, modify to open the transaction.
Read-only transaction: When the query is executed, the transaction will also be started.
Transaction isolation level
The transaction isolation level reflects the attitude of the transaction when the transaction is submitted for concurrent access
- ISOLATION_DEFAULT default level, which belongs to one of the following
- ISOLATION_READ_UNCOMMITTED can read uncommitted data
- ISOLATION_READ_COMMITTED can only read the submitted data to solve the dirty reading problem (Orale default level)
- ISOLATION_REPEATABLE_READ whether to read the modified data submitted by other transactions to solve the problem of non-repeatable reads (Mysql default level)
- ISOLATION_SERIALIZABLE whether to read the data added by other transactions to solve the problem of phantom reading
Transactional behavior
REQUIRED: If there is currently no transaction, create a new transaction, if there is already a transaction, add to this transaction, the general choice (default)
SUPPORTS: support the current transaction, if there is no transaction, it will be executed in a non-transactional way (no Transaction)
MANDATORY: use the current transaction, if there is no transaction currently, throw an exception
REQUERS_NEW: create a new transaction, if the current transaction is in progress, suspend the current transaction
NOT_SUPPORTED: perform operations in a non-transactional way, if there is a transaction Suspend the current transaction
NEVER: run in a non-transactional mode, if a transaction currently exists, throw an exception
NESTED: if there is currently a transaction, it is executed in a nested transaction, if there is no transaction currently, perform a similar action of REQUIRED