spring@transactional annotations

Today encountered a transaction rolled back because it had been marked as Rollback-only error, the controller calls the service method always throws this exception. At first just think that the method in the service throws an exception, the transaction rollback, but the observation log every time the entire method is executed, no exception, but still rollback, baffled its solution. Then Baidu searched a bit to locate the problem.

It turned out that the method that I called the other service was caused by nested transactions because the level of the transaction's propagation caused the outer method to roll back together.

Simply put: MethodA added @transactional, called MethodB also added @transactional.

In the methodb throw abnormal, transaction is set to Rollback-only, but methoda normal digestion, processing off the exception is not thrown out, continue to normal execution.

At the end of the MethodA, transaction will take a commit, but transaction has been set to rollback-only. So this error will occur.

Locating the problem is a good solution, as long as you let MethodB open a new transaction--@Transactional (propagation=propagation.requires_new).

-----------------------------------------------------------Split Line----------------------------------------------------------- ------------------------

In addition, when using Spring's annotated transaction management, the propagation behavior and isolation level of the transaction may be a bit overwhelming, as described below in detail for easy reference.

How to annotate things: @Transactional

When marked in front of a class, all methods in the marked class are handled by the object, for example:

@Transactional public class Testservicebean implements Testservice {}

When certain methods in a class do not require things:

@Transactional public class Testservicebean implements Testservice {private Testdao dao; public Vo ID setdao (Testdao dao) {this. dao = DAO; } @Transactional (propagation =propagation.not_supported) public ListGetAll () {return null;}}

Introduction to the act of spreading things:
@Transactional (propagation=propagation.required)
If there is a transaction, then join the transaction and create a new one (by default)
@Transactional (propagation=propagation.not_supported)
Container does not open transactions for this method
@Transactional (propagation=propagation.requires_new)
Creates a new transaction regardless of whether a transaction exists, the original hangs, the new execution completes, and the old transaction continues
@Transactional (Propagation=propagation.mandatory)
Must be executed in an existing transaction, or throw an exception
@Transactional (Propagation=propagation.never)
Must be executed in a non-transaction, otherwise throws an exception (as opposed to propagation.mandatory)
@Transactional (Propagation=propagation.supports)
If the other bean calls this method and declares the transaction in another bean, the transaction is used. If the other bean does not declare the transaction, then there is no transaction.

Things timeout settings:
@Transactional (timeout=30)//default is 30 seconds

Transaction ISOLATION Level:
@Transactional (isolation = isolation.read_uncommitted)
READ UNCOMMITTED data (dirty read, non-repeatable read) basic not used
@Transactional (isolation = isolation.read_committed)
Read committed data (non-repeatable read and Phantom reads occur)
@Transactional (isolation = isolation.repeatable_read)
REPEATABLE READ (phantom read occurs)
@Transactional (isolation = isolation.serializable)
Serialization

MYSQL: Default to Repeatable_read level
SQL Server: Default is read_committed

Dirty reads : One transaction reads uncommitted update data to another transaction
non-repeatable read : In the same transaction, multiple reads of the same data are returned with different results, in other words,
Subsequent reads can be read to the updated data submitted by another transaction. Conversely, "repeatable reads" are repeated in the same transaction
When reading data, it is guaranteed to read the same data, that is, subsequent reads cannot be read to another transaction committed update data
Phantom reads : One transaction reads the insert data that has been committed by another transaction

Description of common parameters in @Transactional annotations

Parameter name	Function description
ReadOnly	This property is used to set whether the current transaction is a read-only transaction, set to True for read-only, false to read-write, and the default value to False. Example: @Transactional (readonly=true)
Rollbackfor	This property is used to set an array of exception classes that need to be rolled back, and when the method throws an exception in the specified exception array, the transaction is rolled back. For example: Specify a single exception class: @Transactional (Rollbackfor=runtimeexception.class) Specify multiple exception classes: @Transactional (Rollbackfor={runtimeexception.class, Exception.class})

Continuation form)

Parameter name	Function description
Rollbackforclassname	This property is used to set an array of exception class names that need to be rolled back, and when the method throws an exception in the specified exception name array, the transaction is rolled back. For example: Specify a single exception class name: @Transactional (rollbackforclassname= "RuntimeException") Specify multiple Exception class names: @Transactional (rollbackforclassname={"RuntimeException", "Exception"})
Norollbackfor	This property is used to set an array of exception classes that do not need to be rolled back, and when a method throws an exception in the specified exception array, the transaction is not rolled back. For example: Specify a single exception class: @Transactional (Norollbackfor=runtimeexception.class) Specify multiple exception classes: @Transactional (Norollbackfor={runtimeexception.class, Exception.class})
Norollbackforclassname	This property is used to set an array of exception class names that do not need to be rolled back, and when a method throws an exception in the specified exception name array, the transaction is not rolled back. For example: Specify a single exception class name: @Transactional (norollbackforclassname= "RuntimeException") Specify multiple exception class names: @Transactional (norollbackforclassname={"RuntimeException", "Exception"})
Propagation	This property is used to set the propagation behavior of a transaction, which can be referenced in table 6-7. Example: @Transactional (propagation=propagation.not_supported,readonly=true)
Isolation	This property is used to set the transaction isolation level of the underlying database, which is used to handle multi-transaction concurrency, usually using the default isolation level of the database, and does not need to be set
Timeout	This property is used to set the time-out seconds for a transaction, and the default value is 1 to never time out

Note the points:
1 @Transactional can only be applied to the public method, for other non-public methods, if the tag @transactional will not error, but the method does not have transactional capabilities.

2 with the Spring transaction manager, Spring is responsible for opening, committing, and rolling back the database. Default run-time exceptions are encountered (the throw new RuntimeException ("comment");) rolled back, that is, the rollback occurs when an exception is encountered that is not checked (unchecked) While encountering exceptions that need to be caught (the throw new Exception ("note");) not be rolled back, that is, an exception that is checked (that is, an exception that is thrown when it is not run-time, the exception that the compiler checks for is called a check exception or a check exception). We need to specify a way to let the transaction roll back. If you want all exceptions to be rolled back, add @Transactional (Rollbackfor={exception.class, other exceptions}). If you let unchecked exceptions do not roll back: @Transactional ( Notrollbackfor=runtimeexception.class)
As follows:
@Transactional (Rollbackfor=exception.class)//Specify Rollback, rollback when an exception Exception is encountered
public void MethodName () {
throw new Exception ("note");

}
@Transactional (Norollbackfor=exception.class)//Specifies no rollback and encounters a run-time exception (the throw new RuntimeException ("note");) is rolled back
Public Itimdaoimpl Getitemdaoimpl () {
throw new RuntimeException ("note");
}

3. @Transactional annotations should only be applied to the public visibility method. If you use @Transactional annotations on protected, private, or package-visible methods, it will not error, but this annotated method will not show the configured transaction settings.

4. @Transactional annotations can be applied to interface definitions and interface methods, class definitions, and public methods of classes. Note, however, that only @Transactional annotations appear to be less than the open transaction behavior, which is only a meta-data that can be used to identify @Transactional annotations and the beans that are configured appropriately to have transactional behavior. In the above example, it is the presence of the element that opens the transaction behavior.

5. The spring team's recommendation is that you use @Transactional annotations on specific classes (or methods of classes) rather than on any interface that the class implements. You can certainly use @Transactional annotations on the interface, but this will only take effect if you set up an interface-based proxy. Because annotations are not inherited, this means that if you are using a class-based proxy, the transaction's settings will not be recognized by the class-based proxy, and the object will not be wrapped by the transaction proxy (it will be identified as critical). Therefore, accept the suggestions from the spring team and use @Transactional annotations on specific classes.

[email protected] annotations