Spring-to-Hibernate transaction management

On spring transaction management Let's think about how we do data manipulation in hibernate when we don't use 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:

What happens to our code after spring's integration of our hibernate? Integration, then, we are no longer every time to take the session for data operations, do not need to open the transaction every time, commit the transaction, we only need spring to provide us with a hibernatetemplate, we We can manipulate the data directly using the data manipulation methods provided by this class. We do not see the code of the transaction, then does spring actually encapsulate the transaction in his method of operation? Some people directly hibernatetemplate inside to provide the method to manipulate data, success, some people but also failed, this is what is going on? In fact, it depends on how we integrate our Hibernate and spring, and if, in the process of integration, we discard the Hibernate.cfg.xml file and configure the data source directly in the spring configuration file, Then you can directly use the hibernatetemplate inside the method is able to successfully manipulate the data, if you still use Hibernate.cfg.xml to configure the data source, Reference the Hibernate.cfg.xml file in the spring configuration file, then you cannot succeed, the reason is because if you use Hibernate.cfg.xml file to configure the data source, as we said earlier, hibernate defaults to committing the transaction manually, and the method provided by Hibernatetemplatel does not provide a transaction commit. And if you use spring's configuration file to configure the data source, Sping is automatically committed by default, so it succeeds if you want to set spring to manual commit you can configure it in the configuration file:

<property name= "Defaultautocommit" >    

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

• Configuration transaction Manager;
• The propagation characteristics of the transaction;
• Those classes those methods use the transaction.

  <!--Configure the transaction manager to assign its role to Sessionfactory to handle the transaction to spring <bean id= "TransactionManager" class= " Org.springframework.orm.hibernate3.HibernateTransactionManager "> <property name=" sessionfactory "> < Ref bean= "Sessionfactory"/> </property> </bean><!--Configuration Transaction propagation characteristics--<tx:advice id= "Txadvice "Transaction-manager=" TransactionManager "> <tx:attributes> <tx:method name=" save* "propagation=" Requir ED "/> <tx:method name=" delete* "propagation=" REQUIRED "/> <tx:method name=" update* "propagation=" REQUIRED "/> <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 transactions--<aop:config> <aop:po Intcut id= "Allservicemethod" expression= "Execution (* com.coe.service.*.* (..))" /> <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.

Top

1

Step

Spring-to-Hibernate transaction management