Declarative transaction
1 programmatic transaction
by the transaction control programmers to write the code
example is the programmatic transaction OpenSessionInView
2 declarative transaction
transaction control code has been written by the spring, the programmer only needs to declare a method which requires transaction control and how to control affairs
3 declarative transaction are directed to methods in the class ServiceImpl
declarative transaction are directed to methods under ServiceImpl class
notification (advice) transaction-based manager of
six declarative transaction attribute interpretation
1 name = "" what methods need transaction control, which support the * wildcard
2 readonly = "boolean" whether it is read-only transaction
if it is true, telling the database transaction is read-only affairs, general affairs lock will not join, will have a performance upgrade, the query method, it is recommended use this property
database for read-only transaction and commits the transaction process will be different, to commit the transaction, the database management system will add a series of locks and other matters, and read-only transactions contrary
if it is false, then the transaction is required to submit transactions , it is recommended to add, delete, modify operation using the lower, the default value fa lse
Transaction property
When you declare a transaction some occasions, we used the @Transactional (readOnly = false, propagation = Propagation.REQUIRED).
Middle parameter readOnly, propagation we call transaction attributes. It is the basic configuration of the transaction. Transaction attributes are five areas: communication behavior, isolation level, transaction timeout, rollback rules, whether read-only.
We can see the attributes of the interface TransactionDefinition, to return to the four basic transaction attributes:
public interface the TransactionDefinition { int getPropagationBehavior (); // propagation behavior. int getIsolationLevel (); // isolation level. The transaction manager which controls another transaction to which data can be seen in this transaction. int getTimeout (); // transaction must be completed within the number of seconds. boolean isReadOnly (); // whether the transaction is read-only. The transaction manager can be optimized in accordance with the return value to ensure that the transaction is a read-only }
This talk about the transaction isolation level (isolation level)
database is to be shared by the majority of customers visit, then it is uncertain following situations may occur during database operations.
Update loss (Lost update)
both transactions simultaneously update his data, a transaction updates the data to another transaction updates to the data covered. For example, CMS systems, both open simultaneously modify an article, a person first save, save after another, after saving the man on the cover save the contents of the first, which resulted in lost updates.
This is because the system does not perform any operation lock, so concurrent transaction has not been isolated. Problems caused by concurrent transactions, the "lost updates" should generally be avoided completely. But to prevent lost updates, and can not rely on database transactions controller to address applications that require data to be updated add the necessary locks to solve, therefore, prevent lost updates should be the responsibility of the application.
Dirty read (Dirty reads)
a read transaction to another operation result data uncommitted transactions. This is very dangerous, because it is likely that all operations are rolled back.
Non-repeatable read (Non-repeatable Reads)
a read transaction was repeated twice on the same data line, but get different results. For example, after a data read transaction T1, T2 its transaction has been modified to obtain a different value of the previous transaction T1 when the data is read again. Also known as virtual read.
Magic Reading (Phantom Reads)
transactions two queries during operation, the second query result contains the first data do not appear in the query, or missing data appearing in the first query (this does not require two the same queries in SQL statements). This is because there is another transaction inserts data caused in the course of two queries.
Non-repeatable read focus is to modify a record field, phantom read focus is new or delete records.
For the former, just lock the recording conditions are met. For the latter, the condition to lock and close the recording.
"Dirty read", "non-repeatable read" and "phantom read", they are actually reading the database consistency problem, it must provide a mechanism by the database transaction isolation to resolve.
Transaction isolation level
in order to avoid situations that appears above the standard SQL specification defines four transaction isolation levels, from low to high was Read uncommitted, Read committed, Repeatable read , Serializable, four levels can be solved one by one dirty reads, non-repeatable read, phantom read these types of problems.
Uncommitted read (the Read Uncommitted)
the Spring identity: ISOLATION_READ_UNCOMMITTED. Allow dirty reads but not lost updates. If a transaction has been started writing data, another transaction is allowed to simultaneously write, but allows other transactions to read the trip data. The isolation level can be "exclusive write locks" to achieve.
Read committed (the Read Committed)
the Spring identity: ISOLATION_READ_COMMITTED. Allows unrepeatable reads but not dirty reads. This can be "instantly shared read locks" and "exclusive write locks" to achieve. Read data transaction allows other transactions continue to access the rows of data, but write uncommitted transactions will prevent other transactions from accessing the row.
Repeatable read (Repeatable the Read)
the Spring identification: ISOLATION_REPEATABLE_READ. Prohibited non-repeatable reads and dirty reads, but sometimes phantom read data may occur. This "exclusive write locks" through "shared read locks" and implementation. Read data transaction would be prohibited by a write transaction (but allowing the read transaction), the write transaction to prohibit any other transactions.
Serialization (the Serializable)
the Spring identification: ISOLATION_SERIALIZABLE. Provide strict transaction isolation. It requires serialization of the transaction, a transaction can be performed by one, rather than concurrently. Only through the "row-level locking" can not be achieved transaction serialization, it must ensure that the newly inserted data is not just execute a transaction query access to through other mechanisms.
The higher the isolation level, the more it can ensure the integrity and consistency of the data, but the impact on concurrent performance is also greater. For most applications, the database system can give priority to the isolation level to Read Committed. It is possible to prevent dirty reads, but also has better concurrent performance. Although it will lead to non-repeatable read, phantom read and II lost update these concurrency problems, in individual cases such problems may occur, the application can be made using pessimistic locking or optimistic locking to control.
Spring at the same time providing an identity: ISOLATION_DEFAULT. It represents the back-end database using the default isolation level. Most database default transaction isolation level is Read committed, such as Sql Server, Oracle. MySQL's default isolation level is Repeatable read.
These are the isolation, we now introduce transaction propagation level propagation
propagation values are as follows:
REQUIRED: (default value) if you currently have a transaction, executed in a transaction, if no transaction, a new transaction
SUPPORTS: If you currently have a transaction, executed in a transaction, if no transaction, in non the next transaction status
MANDATORY: must be executed within a transaction, if you currently have a transaction, executed in a transaction, if there is no transaction, the direct error
Required_NEW: it must be executed within a transaction, if no transaction, a new transaction, if you currently have transaction, the current transaction pending
NOT_SUPPORTED: must be performed in a non-transaction if no transaction, the normal execution, if you currently have a transaction, the current transaction will hang
NEVER: must be performed in a non-transactional state, if no transaction , normal execution, if you currently have a transaction, the error
nESTED: transaction execution must state, if there is no transaction, a new transaction, if the current transaction has created a nested transaction