This article will introduce five properties in accordance with declarative transactions:
- Transaction propagation mechanism
- Transaction isolation mechanism
- Read-only
- Transaction Timeout
- Rollback rules
Spring transaction propagation mechanism
Characteristics of the transaction
- Atomicity (Atomicity): the transaction is an atomic operation, a series of actions. Atomicity of transactions to ensure that actions are either completed or totally ineffective.
- Consistency (Consistency): Once the transaction is completed (regardless of success or failure), the system must ensure that its business model in a consistent state, but will not be part of the complete partial failure. In reality, the data should not be destroyed.
- Isolation (Isolation): There may be many transactions will also deal with the same data, and therefore should be open to every transaction with other transaction isolation to prevent data corruption.
- Persistent (Durability): Once the transaction is completed, no matter what system error occurs, its results should not be affected, so you can recover from any system crashes. Under normal circumstances, the results of the transaction is written to persistent memory.
Spring transaction configuration
Spring support programmatic transaction management and declarative transaction management in two ways.
1. programmatic transaction management
Programmatic transaction management is intrusive transaction management, use TransactionTemplate or directly PlatformTransactionManager, for programmatic transaction management, Spring recommended TransactionTemplate.
2. declarative transaction management
Declarative transaction management built on AOP, which is essentially a method to intercept before and after, and then create or join a transaction before the target method begins, after the execution of the target method committed or rolled back under the circumstances to perform.
Every achieve programmatic transaction must achieve alone, but large business complex function, use programmatic transaction will be painful, and different declarative transaction, declarative transaction belong to non-invasive, does not affect the implementation of business logic, only need to do the relevant business rules declared in the configuration file or by way of notes, you can apply business rules to business logic.
Declarative transaction management is clearly superior to programmatic transaction management, Spring this is a non-invasive way of programming advocated. The only downside of the place is the size of declarative transaction management is the method level, and programmatic transaction management is to a block of code, but you can configure and declarative transaction management by means of extraction method.
Propagation mechanism affairs
Propagated transaction nested transaction is generally used in a scene, such as a transaction which method a transaction calls another method, the two methods are each as an independent method of transaction commit or inner layer to the outer layer combined with the transaction commits, this is the configuration propagation mechanism needs to determine how to execute the transaction.
Common transaction propagation mechanism is as follows:
- PROPAGATION_REQUIRED
the Spring default propagation mechanism, can meet most business needs, if there is the outer layer of the transaction, the current transaction is added to the outer layer of the transaction, a commit, a rollback. If the outer layer is no transaction, a new transaction execution - PROPAGATION_REQUES_NEW
propagation mechanism of the transaction is to open a new transaction every time, while the outer layer of the pending transaction when the current transaction is finished, the upper resume execution of the transaction. If the outer layer is no transaction, the enforcement branch to the current newly opened - PROPAGATION_SUPPORT
If the outer layer of the transaction, the transaction is added to the outer layer, the outer layer if no transaction is performed directly using a non-transactional way. Totally dependent on the outer layer of affairs - PROPAGATION_NOT_SUPPORT
the propagation mechanism does not support transactions, if there is the outer layer of the transaction is pending, finished executing the current code, then restore the outer transaction, regardless of whether an exception would not roll back the current code - PROPAGATION_NEVER
the propagation mechanism is not supported by the outer transaction, that is, if there is a transaction on the outer thrown - PROPAGATION_MANDATORY
and NEVER the contrary, if the outer layer is no transaction, an exception is thrown - PROPAGATION_NESTED
features of the propagation mechanism is save state savepoint, the current transaction is rolled back to a point, so as to avoid all nested transactions are rolled back, i.e. each respective rollback, the transaction is not abnormal if the child eat, substantially or it will cause all of the rollback.
Propagation rule answers the question: Can a new transaction should be initiated or is suspended, or whether the method should be run in a transactional context.
Transaction isolation level
The extent to define a transaction isolation level transaction may be affected by the activities of other concurrent business activities, the transaction isolation level can imagine the degree of selfishness for this transaction transaction processing data.
In a typical application, multiple transactions run simultaneously, often in order to complete their work and operate on the same data. Although concurrent is required, but it will cause the following problems:
- Dirty read (Dirty read)
dirty read occurs when a transaction reads another transaction to be rewritten but not yet submitted data. If these changes are later rolled back, then the first transaction reads the data will be invalid. Non-repeatable read (Nonrepeatable read)
is not a transaction occurs repeatedly read the same query two or more times, but the result is not the same for each query. This is usually due to other concurrent transactions between the two queries to update the data.Non-repeatable read focus changes.
Magic Reading (Phantom reads)
phantom reads and non repeatable read. When after a transaction (T1) is read several rows, another concurrent transaction (T2) is inserted into a number of records, phantom read occurs. In subsequent queries, the first transaction (T1) will find some extra had no record of.Magic Reading focus on added or deleted.
Under ideal conditions, it will be completely isolated between the transaction, which can prevent these problems. However, the complete isolation can affect performance, since isolation often comes to locking in a database record (and sometimes lock table). Completely isolated from each other waiting for the transaction to complete the required work, it will hinder concurrency. Thus, the isolation can choose different levels according to the traffic scenario.
| Isolation Levels | meaning |
|---|---|
| ISOLATION_DEFAULT | Use the back-end database default isolation level |
| ISOLATION_READ_UNCOMMITTED | Allowed to read changes have not been submitted. May lead to dirty reads, non-repeatable reads or phantom reads. |
| ISOLATION_READ_COMMITTED | (Oracle default level) allows reading from concurrent transactions that have been submitted. It prevents dirty reads, but phantom reads and non-repeatable read may still occur. |
| ISOLATION_REPEATABLE_READ | (MYSQL default level) the results of the same field of multiple reads of the same, unless the data is changed current transaction itself. Prevents dirty reads and non-repeatable read, phantom read but may still occur. |
| ISOLATION_SERIALIZABLE | Full compliance ACID isolation levels, to ensure that does not happen dirty reads, non-repeatable read and phantom read. This is the slowest of all the isolation levels, as it usually is by completely locking the data table is currently involved in the transaction to complete. |
Read-only
If a transaction is only performed on the database read operation, the database might use the read-only transaction characteristics, take some optimization measures. To apply a transaction statement by the read-only back-end database can give a chance to those it considers appropriate optimization measures. Since the read-only optimization measures at the time a transaction is initiated by the back-end database implementation, therefore, only those methods have the potential to start a new transaction propagation behavior (PROPAGATION_REQUIRES_NEW, PROPAGATION_REQUIRED, ROPAGATION_NESTED) of, the transaction will be declared only reading makes sense.
Transaction Timeout
In order for an application to perform well, its business does not run too long. Therefore, the next feature is its declarative transaction timeout.
Assuming that the transaction run time becomes extremely long, because the transaction may involve a lock on the database, so the long-running transactions unnecessarily take up database resources. Then you can declare a transaction automatically rolled back after a certain number of seconds, without waiting for the end of its own.
As the clock in overtime when a transaction is started in the beginning, so that only those methods for propagation behavior (PROPAGATION_REQUIRES_NEW, PROPAGATION_REQUIRED, ROPAGATION_NESTED) may have to start a new transaction, the transaction timeout statement makes sense.
Rollback rules
In the default setting, the transaction is rolled back only exception (runtime exception) run the event, and in that there is no roll back by check exception (checked exception) (EJB rollback behavior and this behavior is consistent).
However, you can declare as a runtime exception as rollback exception occurs in a particular subject to inspection. Similarly, you can also declare a transaction is not rolled back when a specific abnormal, even if the specific exception is the runtime exception.
Spring declarative transaction Configuration Reference
What are the things configuration attributes can be configured? Simply use the following reference
- The spread of affairs:
the @Transactional (propagation = Propagation.REQUIRED) - Transaction isolation level:
the @Transactional (Isolation = Isolation.READ_UNCOMMITTED)
Read uncommitted (dirty read will not be repeated reading) substantially not used
- Read-only:
@Transactional (= readOnly to true)
This property is used to set whether the current transaction is a read-only transaction, as provided for read-only true, false, said writable, default is false. - Timeout of affairs:
the @Transactional (timeout = 30) - Rollback:
Specify a single exception classes: @Transactional (rollbackFor = RuntimeException.class)
specify multiple exception classes: @Transactional (rollbackFor = {RuntimeException.class, Exception.class})
This attribute is used to set the required array rollback exception class, when the method specified Exceptions Exceptions thrown array, then the transaction is rolled back.
Finally, my experience is limited to a limited level, readers are welcome valuable suggestions and comments on the text of the opinion. If you want to get more resources or want to learn more and exchange of technology enthusiasts together, I can focus on the public number "whole food engineer Xiaohui," replies the background Keywords receive learning materials, into the front and back end technology exchange group and a programmer sideline group. Programmers also can join the group sideline Q group: 735 764 906 with the exchange.
