The understanding of spring and Hibernate integrated transaction management

Before we talk about spring transaction management, let's think about how we do data manipulation in hibernate when we're not using spring. In Hibernate we do one operation at a time we have to open the transaction, then the data operation, and then commit the transaction, close the transaction, we do this because hibernate default transaction autocommit is False, he needs us to manually commit the transaction, If you do not want to commit the transaction manually every time, you can set it as a transaction autocommit in the Hibernate.cfg.xml my file:

XML code

1 <property name= "Defaultautocommit" >  2     <value>false</value >  3

Even though we set the transaction commit mode to Automatic, it can do data manipulation, but this does not meet our actual business needs, because sometimes after I save a data, I want him to continue to save another piece of data, I want to save two or more after the transaction commit, so that if the error, We can roll back, guarantee the consistency of the data, or both succeed or fail, and then we can't commit the transaction automatically after each piece of data is saved, because they are not in the same transaction, and we cannot ensure that the data is consistent across rows. So at this point we need to manually configure our transactions, which requires the transaction management mechanism provided by spring for Hibernate, the transaction management that spring provides can be divided into two categories: programmatic and declarative, programming, actually in the code to control, Like hibernate operation data, there are limitations to opening transactions and committing transactions, so we typically use declarative to configure our transactions.

Declarative transaction configuration is mainly divided into the following steps:

1. Declarative transaction Configuration

(1) Configure the transaction manager;

(2) The communication characteristics of the transaction;

(3) Those classes those methods use the transaction.

1<!--Configure the transaction manager to assign its role to the sessionfactory to give the transaction to spring to process.2   3<bean id= "TransactionManager"class= "Org.springframework.orm.hibernate3.HibernateTransactionManager" >4<property name= "Sessionfactory" >5<ref bean= "Sessionfactory"/>6</property>7</bean>8   9<!--The propagation characteristics of a configuration transaction-Ten<tx:advice id= "Txadvice" transaction-manager= "TransactionManager" > One<tx:attributes> A<tx:method name= "save*" propagation= "REQUIRED"/> -<tx:method name= "delete*" propagation= "REQUIRED"/> -<tx:method name= "update*" propagation= "REQUIRED"/> the<tx:method name= "get*" read-only= "true" propagation= "not_supported"/> -<tx:method name= "*" read-only= "true"/> -</tx:attributes> -</tx:advice> +    -<!--which methods of those classes participate in the transaction-- +<aop:config> A<aop:pointcut id= "Allservicemethod" expression= "Execution (* com.coe.service.*.* (..))" /> at<aop:advisor pointcut-ref= "Allservicemethod" advice-ref= "Txadvice"/> -</aop:config>

When we configure transactions, we generally set the transaction boundary to the service layer, which is your business logic layer, because we are often in our business logic layer to do some of our columns of data operations, if placed in the DAO data layer, its granularity is too small. In addition, if we configure the transaction at the business logic level, it is also good for our level two cache, which we will find when we are actually working on it.

2. Writing business logic methods

At this point we can write our business logic method in our business logic layer using the data manipulation method provided in Hibernatetemplate, of course, our method must be configured in our transaction configuration, with Save,delete,update, Get to do the beginning of our method. It is important to note that the run-time exception is not rolled back by default (including inheriting the RuntimeException subclass), and the normal exception is not rolled.

Finally, we summarize some of the communication characteristics of the transaction:

1. propagation_required: If there is a transaction, the current transaction is supported. If no transaction is opened;

2. Propagation_supports: If there is a transaction, the current transaction is supported. If there is no transaction, the execution of the non-transaction;

3. Propagation_mandatory: If a transaction already exists, the current transaction is supported. Throws an exception if there is no active transaction;

4. Propagation_requires_new: Always open a new transaction. If a transaction already exists, the existing transaction is suspended;

5. propagation_not_supported: Always execute in a non-transactional manner and suspend any existing transactions;

6. Propagation_never: Always executes in a non-transactional manner, and throws an exception if there is an active transaction;

7. propagation_nested: If an active transaction exists, it is run in a nested transaction. If there is no active transaction, it is performed by the Transactiondefinition.propagation_required property.

The understanding of spring and Hibernate integrated transaction management