"Go" Spring uses annotations for transaction management

Spring uses annotations for transaction management

Original link Http://www.cnblogs.com/younggun/archive/2013/07/16/3193800.html#top

Steps to use:

Step one, introducing the <tx:> namespace in the spring configuration file <beans xmlns= "Http://www.springframework.org/schema/beans" xmlns: Xsi= "Http://www.w3.org/2001/XMLSchema-instance" xmlns:tx= "Http://www.springframework.org/schema/tx" xsi:schemalocation= "Http://www.springframework.org/schema/beans http://www.springframework.org/schema/ Beans/spring-beans-2.0.xsd http://www.springframework.org/schema/tx http://www.springframework.org/ Schema/tx/spring-tx-2.0.xsd "> Step two, beans with @transactional annotations are automatically configured for declarative transaction support

<!--Transaction manager configuration, hibernate single data source transaction-<BeanId= "Defaulttransactionmanager"Class= "Org.springframework.orm.hibernate3.HibernateTransactionManager"> <property Span style= "color: #ff0000;" >name= "Sessionfactory"  ref = "Sessionfactory" /> </bean> <!-- use annotation to define transactions --> <tx:annotation-driven transaction-manager= "Defaulttransactionmanager"  Proxy-target-class= " True "/>           

step three, in the interface or class declaration, write a @transactional. If only write on the interface, the implementation of the interface class will inherit, interface implementation of the specific method of the class, you can override the settings at the class declaration @Transactional//class-level annotations, applicable to all public methods in the class

Propagation behavior and isolation level of a transaction

When you use spring's annotated transaction management, the propagation behavior and isolation level of the transaction may be a bit overwhelming, as detailed below for easy access.

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

When certain methods in a class do not require things:

@Transactionalimplements testservice {       privatevoidThis.dao = dao;} @ Transactional (propagation = publiclist<object>null;}}        

Introduction to the act of spreading things: @Transactional (propagation=propagation.required) If there is a transaction, then join the transaction, then create a new (by default) @Transactional (propagation= propagation.not_supported) container does not open a transaction for this method @Transactional (propagation=propagation.requires_new) creates a new transaction regardless of the existence of a transaction. The original hangs, the new execution is complete, the old transaction continues @Transactional (propagation=propagation.mandatory) must be executed in an existing transaction, or an exception is thrown @Transactional ( Propagation=propagation.never) must be executed in a non-transactional transaction, otherwise throwing an exception (as opposed to propagation.mandatory) @Transactional (propagation= Propagation.supports) If other beans call this method and declare the transaction in another bean, then use the transaction. If the other bean does not declare the transaction, then the transaction is not used.

thing timeout setting: @Transactional (timeout=30)//default is 30 seconds

Transaction ISOLATION Level: @Transactional (isolation = isolation.read_uncommitted) reads uncommitted data (dirty reads, non-repeatable reads) do not use @Transactional ( isolation = isolation.read_committed) Read Committed data (non-repeatable read and Phantom Read) @Transactional (isolation = isolation.repeatable_read) repeatable READ (phantom reads occur) @Transactional (isolation = isolation.serializable) serialization

MYSQL: Default is repeatable_read level SQL Server: default is read_committed

Dirty Read : One transaction read to another transaction uncommitted update data is not repeatable read : In the same transaction, multiple reads of the same data return different results, in other words, subsequent reads can be read to another transaction committed update data. Conversely, "repeatable read" can guarantee the same read data when read data multiple times in the same transaction, that is, subsequent reads cannot be read to another transaction committed update data Magic Read : One transaction reads the insert data that has been committed by another transaction

description of common parameters in @Transactional annotations

readonly

parameter name	function description

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: 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 functionality.
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 the exception that needs to be caught (the throw new Exception ("comment");) does not roll back, that is, when a check exception is encountered (that is, an exception that is thrown when it is not run-time, the compiler checks for an exception that is called a check exception or a check exception), we specify the way to let the transaction roll To get all the exceptions rolled back, add @Transactional (Rollbackfor={exception.class, other exceptions}). If unchecked exception is not rolled 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, encounters a run-time exception (throw new RuntimeException ("note");) rolls back public Itimdaoimpl Getitemdaoimpl () {throw new RuntimeException ("comment");}

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 actually the presence of the <tx:annotation-driven/> 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.

"Go" Spring uses annotations for transaction management