spring transaction management (reproduced)

[size=x-large][size=x-large] Original address: http://www.cnblogs.com/macula/archive/2013/05/08/3066914.html

[color=blue][/color]Every The second class leader, when it comes to Spring affairs, everyone always has a lot of questions. In fact, Spring affairs are not difficult, and it may be difficult to understand when you first contact them. Today we will talk about Spring's transaction management mechanism in detail. , mainly transaction management for Hibernate.

Before talking about Spring transaction management, let's think about how we operate data in Hibernate when we don't use Spring. In Hibernate, every time we perform an operation, we must first open the transaction, then perform the data operation, then submit the transaction, and close the transaction. The reason for this is because Hibernate's default transaction auto-commit is false, which is We need to manually commit the transaction manually. If you don't want to manually commit the transaction every time, you can set it to auto-commit the transaction in the hibernate.cfg.xml file:

<property name="hibernate.connection.autocommit"> true</property>
When we Spring integrated our Hibernate, what happened to our code? After integration, we no longer need to use Session for data operations every time, and we don’t need to open transactions and submit transactions every time. We only need a HibernateTemplate provided by Spring, and we directly use this class to give We provide data manipulation methods to manipulate data. We can't see the code about transactions anymore, so does Spring encapsulate transaction processing in its operation methods? Some people operate data directly with the methods provided in HibernateTemplate, and they succeed, while others fail. What's going on? In fact, it depends on how we integrate our Hibernate and Spring. If we abandon the hibernate.cfg.xml file during the integration process and configure the data source directly in Spring's configuration file, then you can directly use HibernateTemplate The methods provided in it can successfully operate the data. If you still use hibernate.cfg.xml to configure the data source and refer to the hibernate.cfg.xml file in the Spring configuration file, then you cannot succeed. The reason for this is because If you use the hibernate.cfg.xml file to configure the data source, as we said earlier, Hibernate commits the transaction manually by default, and the method provided by HibernateTemplatel does not provide transaction commit, and if you use Spring's configuration file to configure the data Source, Spring is automatically submitted by default, so it will succeed. If you want to set Spring to submit manually, you can configure it in the configuration file:

<property name="defaultAutoCommit">
    <value>false</value>
< /property>
Even if we set its transaction submission mode 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 hope he can continue to save another piece of data, I It is hoped that the transaction will be submitted together after saving two or more pieces of data, so that even if there is an error, we can roll back and ensure the consistency of the data, either all success or failure, at this time, we cannot save a piece of data. Autocommit, because then they are not in the same transaction, we cannot guarantee consistent rows of data. So at this time, we need to manually configure our transactions, which requires the use of the transaction management mechanism provided by Spring for Hibernate. The transaction management provided by Spring can be divided into two categories: programmatic and declarative, programmatic, In fact, it is controlled in the code. Like Hibernate operating data, opening transactions and submitting transactions has certain limitations, so we generally configure our transactions declaratively.

The declarative transaction configuration is mainly divided into the following steps:

1. Declarative transaction configuration

Configure the transaction manager;
the propagation characteristics of the transaction;
those classes and those methods use the transaction.
Copy code
Copy code


    <bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
    <property name="sessionFactory">
    <ref bean="sessionFactory"/>

    </bean>


    <tx:advice id="txAdvice" transaction-manager="transactionManager">
    <tx:attributes>
    <tx:method name="save*" propagation="REQUIRED"/>
    <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>


    <aop:config>
    <aop:pointcut id="allServiceMethod" expression="execution(* com.coe.service.*.*(..))"/>
    <aop:advisor pointcut-ref="allServiceMethod" advice-ref="txAdvice"/>
    </aop:config>
Copy code
Copy code
When we configure transactions, we generally set the transaction boundary to the service layer, which is your business logic layer, because we often do it in our business logic layer Some of our column data operations, if placed in the Dao data layer, the granularity is too small. In addition, if we configure the transaction in the business logic layer, it is also beneficial to our second-level cache, which you will find out when you actually operate it later.

2. Write business logic methods

At this time, we can use the data operation methods provided in HibernateTemplate to write our business logic methods in our business logic layer. Of course, our methods must be the same as those configured in our transaction configuration, use save , delete, update, get do the beginning of our method. It should be noted that by default, runtime exceptions will be rolled back (including subclasses that inherit RuntimeException), and ordinary exceptions will not be rolled back.

Finally, we summarize several propagation characteristics of transactions by the way:

1. PROPAGATION_REQUIRED: If there is a transaction, the current transaction is supported. Open if there is no transaction;

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

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

4. PROPAGATION_REQUIRES_NEW: Always open a new transaction. If a transaction already exists, suspend the existing transaction;

5. PROPAGATION_NOT_SUPPORTED: Always execute non-transactionally and suspend any existing transaction;

6. PROPAGATION_NEVER: Always execute non-transactionally, throw an exception if there is an active transaction;

7. PROPAGATION_NESTED: If an active transaction exists, run in a nested transaction. If there is no active transaction, press TransactionDefinition The .PROPAGATION_REQUIRED property is enforced. [/size][/size]

spring transaction management (reproduced)

Guess you like