Analysis on the difficulties of spring advanced transaction management

1Spring Transaction Propagation Behavior

The so-called transaction propagation behavior is how transactions are propagated between these methods when multiple transactional methods are called each other. Spring supports 7 kinds of transactional propagation behavior

Propagation_required(Join an existing transaction)

If there is no current transaction, create a new transaction, if one is already present, join the transaction. This is the most common and default way.

Propagation_supports(following the environment)

Supports the current transaction and is executed in a non-transactional manner if no transaction is currently in use.

Propagation_mandatory(requires transaction)

Throws an exception if no transaction is currently in use for the current transaction.

Propagation_requires_new(Independent business)

Creates a new transaction, suspending the current transaction if the transaction currently exists.

Propagation_not_supported(non-transactional mode)

Executes the operation in a non-transactional manner, suspending the current transaction if a transaction is currently present.

Propagation_never(excluding transactions)

Executes in a non-transactional manner, throwing an exception if a transaction is currently present.

propagation_nested(nested transactions)

Executes within a nested transaction if the transaction is currently present. If there is currently no transaction, perform a similar operation as propagation_required.

Spring's default transactional propagation behavior is propagation_required, which is suitable for most situations. Assuming that Servivex#methodx () is working in a transactional environment (that is, it is enhanced by spring transactions), assume that the following call chain exists in the program: Service1#method1 ()->service2#method2 () SERVICE3#METHOD3 (), then the 3 methods of these 3 service classes work in the same transaction through spring's transaction propagation mechanism.

If a thread is started in a servicea and a () method, the ServiceB transaction Method B () is executed in this newly created thread. Transaction methods that make nested calls to each other in the same thread work in the same transaction. If these methods of nested calls work in different threads, the transaction methods under different threads work in separate transactions.

2 Multiple data persistence methods transaction management

If you adopt a high-end ORM Technology (HIBERNATE,JPA,JDO) and use a JDBC technology (Spring Jdbc,ibatis), the former session is the encapsulation of the latter connection (Connection), Spring will "be smart enough" to let the former's session encapsulate the latter's connection in the same transactional thread. So, we just have to use the former transaction manager directly. The following table shows the transaction manager for hybrid data access technology:

1 unification of transactions in different durable ways

Spring provides a tool class that can get the binding data connection from the current transaction context, which is datasourceutils. Spring emphasizes that you must use the Datasourceutils tool class to obtain a data connection.

Static Connection dogetconnection (DataSource DataSource)

First try to get the connection from the transaction context, and then get the connection from the data source after the failure;

Static Connection getconnection (DataSource DataSource)

The function of the Dogetconnection method, in fact, is that it calls the Dogetconnection method to get the connection;

static void doreleaseconnection (Connection con, DataSource DataSource)

Release the connection and put it back in the connection pool;

static void release Connection (Connection con, DataSource DataSource)

As with the function of the Doreleaseconnection method, in fact, it calls the Doreleaseconnection method to get the connection;

Test Demo:

@Servicepublic class Testtranscationserviceimpl implements Testtranscationservice {@Autowired private Testtranscati    Ondao Testtranscationdao;        @Override @Transactional public int test () {testtranscationdao.update1 ();               Testtranscationdao.update2 ();    return 0; }}

@Autowired     private jdbctemplate jdbctemplate;    @ Override    public int update1 ()  {         //1. Getting a database connection         Connection con =  Datasourceutils.getconnection (Jdbctemplate.getdatasource ());         Try {            con.preparestatement ("Update  grade_info set grade_name= '  where grade_id=1 '). Executeupdate ();         } catch  (sqlexception e)  {             throw new runtimeexception (e);         }finally {             //2 if the current method does not have context transaction management, releasing the database connection will cause the database connection to leak andnbsp;           //If there is a context transaction, call or do not call the database connection release is no problem              datasourceutils.releaseconnection (con,  Jdbctemplate.getdatasource ());        }         return 0;    }     @Override      public int update2 () {        //3. Get database connection    The database connection for   and 1 is the same connection         Connection con =  Datasourceutils.getconnection (Jdbctemplate.getdatasource ());         TRY {            //4. Database connection and   of this method 1,3 the database connection is different             connection conn  = jdbctemplate.getdatasource(). getconnection ();             conn.close ();         } catch  (sqlexception e)  {             e.printstacktrace ();         }        return jdbctemplate.update ("update  Grade_info set grade_name= ' High school third grade '  where grade_id=1 ');     }

Spring provides a proxy class for each data access technology framework that acquires a tool class and a data source (or its derivatives) of a data connection (or its derivatives) bound by a transactional context.  

2Hibernate and JDBC Mixed usage considerations

because of the hibernate cache, hibernate does not actually send SQL to the database when manipulating the data through Save,update,delete, and hibernation synchronizes state changes in the first cache to the database only when flush () is called.

Hibernate's transaction management automatically calls the flush () operation when a transaction is committed and synchronizes the first-level cache to the database, in which case the SQL statement is generated and sent to the database.

Because of the reasons above, there may be a problem with missing updates when mixing JDBC and hibernate.

When mixed with Hibernate and JDBC, JDBC operations are not synchronized to hibernate cache (level cache and level two cache), and state changes in the hibernate cache are not perceived by JDBC. It is therefore important to pay particular attention to this in mixed use.

Because of the synchronization of transactions in the scenario of mixed data access technology and the cache is out of sync, it is best to use hibernate to complete the read and write operations, and to do the reading with spring JDBC. For example, use spring JDBC for a brief list of queries, and hibernate to maintain the queried data. If you do want to use Hibernate and spring JDBC to read and write data at the same time, you must take into account the problems raised by the Hibernate caching mechanism: You must fully analyze the data maintenance logic and, as needed, call Hibernate's Flush () method, To avoid overwriting spring JDBC changes, maintain Hibernate's cache when spring JDBC changes the database.

Transaction enhancement restrictions for 3Spring

because spring transaction management is based on interface agent or dynamic bytecode technology, transaction enhancement is implemented through AOP.

For an AOP transaction enhancement based on an interface dynamic agent, because the method of the interface is public, this requires that the implementation of the class must be public (not protected,private , etc.), while the static modifier cannot be used. Therefore, the method can implement interface dynamic Proxy can only be used "public" or "public final" modifier method, other methods cannot be dynamic proxy, corresponding also can not implement the AOP enhancement, that is, the spring transaction can not be enhanced.

The scheme of dynamic agent based on Cglib bytecode is an AOP enhancement implanted by extending the enhanced class and dynamically creating subclasses. Because methods that use the final,static,private modifier cannot be overridden by a quilt class, these methods will not be enforced by the AOP enhancement. Therefore, special attention must be paid to the use of these modifiers, so as not to inadvertently become a transaction management.

4Spring transaction management for exception snapping, transaction rollback

Spring's transaction manager only makes exception rollback for unchecked exception , and the error and runtimeexception and their subclasses are unchecked Exception. Other exception are checked exception.

If a try, catch is used in the service layer to catch the exception, causing the exception in the sevice layer to be "trapped" and cannot be thrown to the transaction manager, this creates an illusion to the transaction manager, as if the program is running without any problems, so it does not appear RuntimeException the rollback operation.

The article comes from the online resource collation, self-test by demo

Friendship Link:

"Spring 3.x Enterprise Practical development actual combat " author blog http://stamen.iteye.com/category/209694 has related series blog

The analysis of difficulties and difficulties in Ppt:spring senior affairs management of Baidu Library

Analysis on the difficulties of spring advanced transaction management