@Transactional Spring Configuration Transaction considerations

http://epine.itpub.net/post/8159/526281 @Transactional Spring Configuration transaction considerations

1. Add @transactional annotations where transaction management is required. @transactional annotations can be applied to interface definitions and interface methods, class definitions, and public methods of classes .

2. @Transactional annotations can only be applied to methods of public visibility . 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.

3. Note that only @Transactional annotations appear to be less than open transaction behavior, which is simply a kind of meta data. The configuration element must be used in the configuration file to actually open the transaction behavior.

4. Control whether an interface-based or class-based proxy is created through the element's "Proxy-target-class" attribute value . If the "Proxy-target-class" value is set to "true", then the class-based proxy will function (this requires the Cglib library Cglib.jar in classpath). If the "Proxy-target-class" value is set to "false" or if this attribute is omitted, then the standard JDK interface-based proxy will work.

Standard JDK interface-based proxies will work--
Proxy-target-class= "false"/>

Class-based proxies will work, while Cglib.jar must be in Classpath
Proxy-target-class= "true"/>
-


Non-JTA transactions (that is, non-distributed transactions), when the transaction is configured, you need to specify the DataSource property (non-distributed transaction, the transaction is opened on the link created by the database. )--

JTA transactions (non-distributed transactions), when a transaction is configured, you cannot specify the DataSource property (distributed transaction, which has global transactions to manage database links)-

The biggest difference between the @transactional cglib and the Java Dynamic Agent is that the proxy target object does not implement the interface, then if the annotation is written to the interface method, if the Cglib proxy is used, then the annotation thing is invalidated. It is best to write to the implementation class method in order to maintain the compatibility annotations.

5. The Spring Team recommends using @Transactional annotations on specific classes (or methods of classes) rather than on any interface that the class implements . Using @Transactional annotations on an interface only takes effect if you set up an interface-based proxy. Because annotations are not inherited , this means that if a class-based proxy is being used, the transaction's settings will not be recognized by the class-based proxy, and the object will not be wrapped by the transaction proxy.

6. @Transactional transactions are opened, either interface-based or class-based proxies are created. so in the same class one method calls another method with a transactional method, and the transaction does not work .

Public interface Personservice {
Delete the person with the specified ID
public void Delete (Integer PersonID);

Delete the person,flag of the specified ID
public void Delete (Integer personid,boolean flag);
}

public class Personservicebean implements Personservice {
Private JdbcTemplate JdbcTemplate;

public void Delete (Integer PersonID) {
try{
This.delete (Personid,true)
System.out.println ("delete Success");
}catch (Exception e) {
System.out.println ("delete failed");
}
}

@Transactional
At this point, the transaction is not turned on at all, that is, the database commits the operation by default, that is, the record does not delete the public void Delete (Integer Personid,boolean flag) {
if (flag = = ture) {
Jdbctemplate.update ("Delete from person where id=?", New Object[]{personid},
New Int[]{java.sql.types.integer});
throw new RuntimeException ("Run-time exception");
}
}
}

public class personservicebeantest{
Personservice PS = new Personservicebean ();
Ps.delete (5);
}

7. Spring uses declarative transactions, and by default all database operations are rollback if an unchecked exception occurs inthe annotated database operation method; If the exception that occurs is a checked exception , by default the database operation will be submitted .

--------------------------------------------------------------------------------------------------------------- --------------------------------
Public interface Personservice {
Delete the person with the specified ID
public void Delete (Integer PersonID);

Get person
Public person Getperson (Integer PersonID);
}

Personservicebean implements the Personservice interface, the interface-based or class-based proxy can implement the transaction
@Transactional public class Personservicebean implements Personservice {
Private JdbcTemplate JdbcTemplate;

//Unchecked exception occurred, transaction rollback, @Transactional
public void Delete (Integer PersonID) {
Jdbctemplate.update ("Delete from person where id=?", New Object[]{personid},
New Int[]{java.sql.types.integer});
throw new RuntimeException ("Run-time exception");
}
}

--------------------------------------------------------------------------------------------------------------- ------------------------------------
Public interface Personservice {
Delete the person with the specified ID
public void Delete (Integer PersonID) throws Exception;

Get person
Public person Getperson (Integer PersonID);
}

@Transactional
public class Personservicebean implements Personservice {

A checked exception occurred and the transaction was not rolled back, i.e. the database record could still be deleted.
The exception to the checked requires that we use the Try/catch syntax externally to include the place where the method is called @Transactional
public void Delete (Integer PersonID) throws Exception{
Jdbctemplate.update ("Delete from person where id=?", New Object[]{personid},
New Int[]{java.sql.types.integer});
throw new Exception ("Run-time exception");
}

}
--------------------------------------------------------------------------------------------------------------- ------------------------------------
However, with the exception of checked, it does not roll back the transaction by default, but if we need it for transaction rollback, we can modify its behavior by @transaction this annotation on the Delete method.

@Transactional
public class Personservicebean implements Personservice {

@Transactional(Rollbackfor=exception.class)
Rollbackfor This property specifies that, even if you have a checked exception, it also rolls back the transaction
public void Delete (Integer PersonID) throws exception{
Jdbctemplate.update ("Delete from person where id=?", New Object[]{personid},
New Int[]{java.sql.types.integer});
throw new Exception ("Run-time exception");
}
}
--------------------------------------------------------------------------------------------------------------- ------------------------------------

In Personservicebean this business bean, there are some transactions that do not require transaction management, such as the Getpersons method of acquiring data, Getperson method. Because the @transactional is placed above the class.

At this point, you can take the Propagation transaction property @transactional (propagation=propagation.not_supported), propagation This property specifies the transaction propagation behavior, We can specify that it does not support transactions, and when we write this, the spring container does not open the transaction until the Getpersons method executes .

@Transactional
public class Personservicebean implements Personservice {

@Transactional (propagation=propagation.not_supported)
Then this method will not open the transaction.
Public person Getperson (Integer PersonID)
{
}
}

@Transactional Spring Configuration Transaction considerations