Understanding of spring and hibernate integrated transaction management, springhibernate

Understanding of spring and hibernate integrated transaction management, springhibernate

Before talking about Spring transaction management, let's think about how we perform data operations in Hibernate when we don't need Spring. In Hibernate, each time we perform an operation, we must first start the transaction, then perform the data operation, then commit the transaction, and close the transaction, the reason for doing this is that the default automatic transaction commit of Hibernate is false. It requires manual transaction commit. If you do not want to manually commit the transaction every time, you can go to hibernate. cfg. set xml in my file as automatic transaction commit:

Xml Code

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

 

Even if we set its transaction commit method to automatic, it can perform data operations, but this does not meet our actual business needs, because sometimes after I save a piece of data, I want him to save another piece of data. I want to commit the transaction after saving two or more pieces of data. In this way, even if an error occurs, we can roll back and ensure data consistency, either success or failure. At this time, the transaction cannot be automatically committed after each piece of data is saved, because they are not in the same transaction, and we cannot guarantee the consistent row of data. At this time, we need to manually configure our transactions. This requires the transaction management mechanism provided by Spring for Hibernate. The transaction management mechanism provided by Spring can be divided into two types: programming and declarative programming are actually controlled in the Code. Like Hibernate operating on data, opening transactions and committing transactions have certain limitations, therefore, we usually use declarative statements to configure our transactions.

Declarative transactions are configured in the following steps:

1. Declarative transaction Configuration

 

(1) configure the Transaction Manager;

(2) Propagation Characteristics of transactions;

(3) The methods of those classes use transactions.

1 <! -- Configure the Transaction Manager to specify the sessionFactory to handle the transaction with Spring --> 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 <! -- Configure the transaction propagation feature --> 10 <tx: advice id = "txAdvice" transaction-manager = "transactionManager"> 11 <tx: attributes> 12 <tx: method name = "save *" propagation = "REQUIRED"/> 13 <tx: method name = "delete *" propagation = "REQUIRED"/> 14 <tx: method name = "update *" propagation = "REQUIRED"/> 15 <tx: method name = "get *" read-only = "true" propagation = "NOT_SUPPORTED"/> 16 <tx: method name = "*" read-only = "true"/> 17 </tx: attributes> 18 </tx: advice> 19 20 <! -- Which methods of those classes are involved in the transaction --> 21 <aop: config> 22 <aop: pointcut id = "allServiceMethod" expression = "execution (* com. coe. service. *. *(..)) "/> 23 <aop: advisor pointcut-ref =" allServiceMethod "advice-ref =" txAdvice "/> 24 </aop: config>

When we configure a transaction, we generally set the transaction boundary to the service layer, that is, your business logic layer, because we usually perform data operations on some columns in our business logic layer. If we put them in the Dao data layer, the granularity is too small. In addition, if we configure transactions in the business logic layer, it will also be good for our second-level cache, which will be discovered in actual operations in the future.

2. Compile the business logic method

At this time, we can use the data operation methods provided in HibernateTemplate in our business logic layer to compile our business logic methods, of course, our method must be the same as that configured in our transaction configuration. We use save, delete, update, and get to start with our method. Note that by default, exceptions during runtime will be rolled back (including inheriting the RuntimeException subclass). Normal exceptions will not be rolled back.

At last, let's summarize several Propagation Features of transactions:

1. PROPAGATION_REQUIRED: if a transaction exists, the current transaction is supported. Enabled if no transaction exists;

2. PROPAGATION_SUPPORTS: if a transaction exists, the current transaction is supported. If there is no transaction, it is not the execution of the transaction;

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

4. PROPAGATION_REQUIRES_NEW: always starts a new transaction. If a transaction already exists, the transaction will be suspended;

5. PROPAGATION_NOT_SUPPORTED: Always executes non-transactions and suspends any existing transactions;

6. PROPAGATION_NEVER: Always executes non-transactional operations. If an active transaction exists, an exception is thrown;

7. PROPAGATION_NESTED: if an active transaction exists, it runs in a nested transaction. If no active transaction exists, it is executed according to the TransactionDefinition. PROPAGATION_REQUIRED attribute.