1. propagation level of the transaction
1) @Transactional (propagation = Propagation.REQUIRED): The default level of spring spread affairs, characterized by the use of the level, if a transaction context already exists, then it is added to the transaction execution, if the transaction does not exist in the current context, the New transaction execution, so this level usually suffices to handle most business scenarios.
2) @Transactional (propagation = PROPAGATION.SUPPORTS): literally knew, supports (support), which is characterized by the spread level, if there is a transaction context, the support of the current transaction, added to the transaction execution, if there is no transaction, It performed using a non-transactional way. So, not all packages transactionTemplate.execute code will have transaction support. This is generally not used to handle atoms of non-core business logic operations, fewer application scenario.
3) @Transactional (propagation = PROPAGATION.MANDATORY): The level transaction requires a transaction context must exist, otherwise it will throw an exception! Configure the way the spread level is effectively controlled context of the calling code to add the missing means of ensuring control of affairs. For example, a piece of code can not be invoked to perform alone, but once invoked, there must be included in the case of a transaction, you can use this spread level.
4) @Transactional (propagation = PROPAGATION.REQUIRES_NEW) : to know literally, every time a new transaction, the spread level feature is that every time a new transaction, and at the same time in the context of the pending transaction when new transactions executed after completion of the transaction context and then resume execution.
This is a useful level of propagation, for a scenario: 100 now has a red transmission operation, prior to transmission, do some initialization system, verification, data recording operation, and then send 100 envelopes, then the recording send log, send the log requires 100% accuracy, if the log is not accurate, then the entire logic of the parent transaction rollback.
How to deal with the whole business needs? PROPAGATION.REQUIRES_NEW is through this level of control transaction propagation can be completed. Send a red envelope sub-transaction does not directly affect the parent transaction commit and rollback.
5) @Transactional (propagation = PROPAGATION.NOT_SUPPORTED) : This can also be learned from the literal, not supported (not supported), the current level feature is that if there is a transaction context,
the pending transaction, execution of the current logic, after the end restore the context of the transaction.
This level What are the benefits? It can help you will most likely reduce transaction. We know that the larger the transaction, the more risk there is of it. Therefore, during the processing of a transaction, to ensure that narrow as possible. For example, a piece of code, every time logical operations must be invoked, such as a non-core business cycle logic operations 1000 times. If such a code package in the transaction, the transaction is bound to cause too much, resulting in some hard-considered anomalies. Therefore, this transaction at this level propagate level comes in handy, hold up with the current level of transaction templates on it.
6) @Transactional (propagation = PROPAGATION.NEVER): the transaction is more stringent, spread above the level of a transaction but does not support it, there is a transaction hangs, and PROPAGATION_NEVER spread level requirements can not exist in the context of a transaction, if there is a transaction, to throw a runtime exception is forced to halt!
7) @Transactional (propagation = PROPAGATION.NESTED) : literally can know, nested, nesting level of the transaction. Characterized in that the propagation level, if a transaction is present context, the nested transaction execution, if the transaction does not exist, a new transaction.
So what is it nested transactions?
Nesting is a sub-set of transactions executed in the parent transaction, the transaction is part of the child's parent transaction, before entering the sub-transaction, the establishment of a parent transaction rollback point, called the save point, then execute child transaction, the execution of a transaction can be considered child part of the parent transaction, then the sub-end transaction execution, the father of affairs continue. Focus lies that save point, look at a few issues to understand.
If the child transaction rollback, what will happen?
If the child transaction thrown exception is caught parent transaction, the parent can still submit the transaction; if not caught, then the parent transaction will be rolled back.
If the parent transaction is rolled back, what happens?
Father transaction is rolled back, the child will follow the transaction is rolled back! Why, because the transaction before the end of the parent, the child transaction is not submitted, we say that the transaction is part of the child's parent transaction, it is the truth.
Then: the transaction commits, what is the situation? It is the parent transaction to submit, and then the child transaction commits, or the child to submit the transaction, and then submitted to the parent transaction?
The answer is the second case, then again, child transaction is part of the parent transaction, unified submitted by the parent transaction.
These are the seven spread level of the transaction, in everyday applications, usually to meet a variety of business needs, but in addition to the spread level, in the process of reading the database, if the two transactions to execute concurrently, then the data between each other is how the impact of it?
This need to know about the affairs of another characteristic: the isolation level of the transaction.
2. The transaction isolation level
1) @Transactional (isolation = Isolation.SERIALIZABLE) : the most stringent level, transaction serial execution, resource consumption maximum;
2) the @Transactional (Isolation = Isolation.REPEATABLE_READ): to ensure that a transaction will not be modified by another transaction has been read but not committed (rollback) data. Avoid the situation "dirty read" and "non-repeatable read" but brings more performance loss.
3) @Transactional (isolation = Isolation.READ_COMMITTED) : the default transaction level most popular databases, to ensure that a transaction will not read another concurrent transaction has been modified but not submitted data to avoid the "dirty read" the level for most systems.
4) @Transactional (isolation = Isolation.READ_UNCOMMITTED) : the reading process is not guaranteed to read data illegally.
1: Dirty reads-- reading dirty data. In other words, such as uncommitted transactions of A (also still cached) data is read transaction B to go, if the transaction fails rollback A, B can cause data transaction read is wrong.
2: non-repeatable reads-- non-repeatable read. A read transaction such as the total value of the two data of the same row. In the first read time, total is 100, then put the total transaction data into B 200, A read transaction time, the result is found, it becomes even total 200, causing repeated in the same transaction A transaction read the results are inconsistent, so-called non-repeatable read.
3: phantom reads-- phantom read data. This and similar non-repeatable reads, but also read many of the same transaction inconsistencies. But the inconsistency non-repeatable reads because he wants to take the data is modified, but inconsistent phantom reads the data to be read refers to: execute the same query twice, but the second did not return to first return OK, the line is "phantom" line, that is, the emergence of phantom reads. Such as SELECT * FROM child WHERE id> 100 FOR UPDATE ;, this time table has id = 90, id = 102 two data lines. A transaction returns the first read data line 1, after the transaction table B is inserted into a data id = 101, the second reading of the transaction, the result returned rows 2, the phantom read occurs .
Non-repeatable read focus is modified: the same conditions, you had to read the data, read out the found value is not the same again.
Magic Reading focus is to add or remove: the same conditions, read out the 1st and 2nd number of records that are not the same.
The situation will lead to a transaction isolation level to read invalid data is represented as follows:
Common database default transaction isolation level
MYSQL: The default is REPEATABLE_READ
SQLSERVER: The default is READ_COMMITTED
ORACLE: The default is READ_COMMITTED
3. @ Transactional annotation common parameters Description
1.）readOnly
This property is used to set whether the current transaction is a read-only transaction, as provided for read-only true, false, it said writable, default is false. For example: @Transactional (readOnly = true)
2.）rollbackFor
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. E.g:
Specify a single exception classes: @Transactional (rollbackFor = RuntimeException.class)
Specify multiple exception classes: @Transactional (rollbackFor = {RuntimeException.class, Exception.class})
3.）rollbackForClassName
This property is used to set the exception class name of the array need to be rolled back when the method specified Exceptions Exceptions thrown array name, then the transaction is rolled back. E.g:
Specify a single exception class name: @Transactional (rollbackForClassName = "RuntimeException")
Specify a plurality of exception class name: @Transactional (rollbackForClassName = { "RuntimeException", "Exception"})
4.）noRollbackFor
This property is used to set the array need not be an exception class rollback when the method specified Exceptions Exceptions thrown array, no transaction for rollback. E.g:
Specify a single exception classes: @Transactional (noRollbackFor = RuntimeException.class)
Specify multiple exception classes: @Transactional (noRollbackFor = {RuntimeException.class, Exception.class})
5.）noRollbackForClassName
This property does not need to set the rollback exception class name of the array, when the method specified Exceptions Exceptions thrown in the name of the array, no transaction for rollback. E.g:
Specify a single exception class name: @Transactional (noRollbackForClassName = "RuntimeException")
Specify multiple exception class name:
@Transactional(noRollbackForClassName={"RuntimeException","Exception"})
propagation
This property is used to set the propagation of the transaction, the specific values refer to Table 6-7.
例如：@Transactional(propagation=Propagation.NOT_SUPPORTED,readOnly=true)
isolation
Transaction isolation level is used to set the property of the underlying database, transaction isolation level for concurrent handling of multiple transactions, the default isolation level can be generally used database, the basic need to set
6.）timeout
This property is used to set the timeout in seconds of the transaction, the default value of -1 indicates never expires
4. Points to note:
1) @Transactional can only be applied to public methods, for other non-public way, if marked @Transactional not an error, but the method is not transactional capabilities.
2) transaction manager with the spring, the spring is responsible for the database open, commit, rollback. Default encounter runtime exception (throw new RuntimeException ( "Notes");) will be rolled back, that encounter exceptions are not checked (unchecked) when rollback; encounter exceptions need to capture (throw new Exception ( "Comment ");) is not rolled back, that encounter exceptions under examination (that is, non-runtime exceptions thrown by the compiler checks to check the exception exception called by check or say when abnormal), we need to specify the manner by to make all transaction rollback exceptions are rolled back, to add @Transactional (rollbackFor = {Exception.class, other abnormal}). If let unchecked exception does not roll back: the @Transactional (notRollbackFor = RunTimeException.class)
: follows
rollback @Transactional (rollbackFor = Exception.class) // Specify the rollback, exception is encountered Exception
public void methodName () {
the throw new new Exception ( "Notes");
}
@Transactional (noRollbackFor = Exception.class) // rollback not specified, encounter runtime exceptions (throw new RuntimeException ( "Comment");) rolls back
public ItimDaoImpl getItemDaoImpl () {
the throw a RuntimeException new new ( "Comment") ;
}
3) @Transactional annotation should only be applied to the method of public visibility. If you use @Transactional annotation on the method protected, private or package-visible it will not be an error, but the annotated method will not appear Affairs configured settings.
4) @Transactional can be applied on the public interface defines methods and interface methods, classes, and class definitions. Note, however, occurs only in open @Transactional annotation insufficient transactional behavior, it is merely a metadata annotation can be can be identified and the above-described configuration @Transactional appropriate beans with transactional behavior to be used. In the above example, it is in fact <tx: annotation-driven /> element that switches on the transactional behavior.
5) Spring team's recommendation is that you use @Transactional comment on the specific methods class (or classes), rather than on any interface type to be achieved. Of course you can use @Transactional annotation on an interface, but this will only be when you set it to take effect when the agent interface-based. Because annotations are not inherited, which means that if you are using a proxy class-based, set the transaction will not be recognized based on the proxy class, and the object will not be the Acting packed (to be confirmed severe). Therefore, please accept the recommendation of the Spring team and the @Transactional comment on the specific class.