Spring to hibernate transaction management "Go"

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:

<name= "Hibernate.connection.autocommit">true</    Property 

       What happens to our code after spring's integration with 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 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? Actually here depends on how we integrate our Hibernate and spring, if in the process of integration, We have abandoned the Hibernate.cfg.xml file, directly in the spring configuration file configuration data source, then you directly with 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 configuration data source, as we said earlier, hibernate by default is to manually commit transactions, and Hibernatetemplatel provides a method does not provide transaction commit, and if you use spring configuration file to configure the data source, sping default is self- Submitted, so it will succeed if you want to set spring to manual commit you can configure it in the configuration file:

 <property  Name= "Defaultautocommit" > <value>false </value></< Span style= "color: #800000;" >property>          

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 the sessionfactory to give the transaction to spring to handle-<BeanId= "TransactionManager"Class= "Org.springframework.orm.hibernate3.HibernateTransactionManager"><PropertyName= "Sessionfactory"><RefBean= "Sessionfactory"/></Property></Bean><!--To configure the propagation characteristics of a transaction-<Tx:adviceId= "Txadvice"Transaction-manager= "TransactionManager"><Tx:attributes><Tx:methodName= "save*"Propagation= "REQUIRED"/><Tx:methodName= "delete*"Propagation= "REQUIRED"/><Tx:methodName= "update*"Propagation= "REQUIRED"/><Tx:methodName= "get*"Read-only= "true"Propagation= "Not_supported"/><Tx:methodName="*"Read-only= "true"/></Tx:attributes></Tx:advice><!--Which methods of those classes participate in the transaction--> <aop:config > <aop:pointcut 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. Also, 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.

Spring to hibernate transaction management "Go"