Spring Transaction Configuration

1. Declarative transaction Configuration
* Configuration Sessionfactory
* Configure transaction Manager
* Propagation Characteristics of transactions
* Those classes those methods use the transaction

The specific configuration is as follows:

<!--configuration Sessionfactory--
<bean id= "Sessionfactory" class= "org.springframework.orm.hibernate3.Localsessionfactorybean">
<property name= "Configlocation" >
<value>classpath:hibernate.cfg.xml</value>//thisClasspath is the one that spring provides for us to read files in the CLASSPATH environment .
</property>
</bean>

<!--configuration Transaction Manager-
<bean id= "TransactionManager" class= "Org.springframework.orm.hibernate3.HibernateTransactionManager" >
<property name= "Sessionfactory" >
<ref bean= "Sessionfactory"/>
</property>
</bean>

<!--Those kinds of methods that use transactions--
<aop:config>
<aop:pointcut id= "Allmanagermethod" expression= "Execution (* com.bjpowernode.usermgr.manager.*.* (..))" />
<aop:advisor pointcut-ref= "Allmanagermethod" advice-ref= "Txadvice"/>//<aop:advisder> can be understood as aspect, because he is composed of pointcut and advice.
</aop:config>

<!--transaction propagation characteristics--
<tx:advice id= "Txadvice" transaction-manager= "TransactionManager" >
<tx:attributes>
<tx:method name= "add*" propagation= "REQUIRED"/>
<tx:method name= "del*" propagation= "REQUIRED"/>
<tx:method name= "modify*" propagation= "REQUIRED"/>
<tx:method name= "*" propagation= "REQUIRED" read-only= "true"/>
</tx:attributes>
</tx:advice>

That way you don't have to write the code for the management transaction in the code:

public void AddUser (user user)
Throws Exception {
This.getsession (). Save (user);
This.gethibernatetemplate (). Save (user);

Log log = new log ();
Log.settype ("Operation Log");
Log.settime (New Date ());
Log.setdetail ("XXX");

Logmanager.addlog (log);

throw new Exception ();
}

2. Writing business logic methods
* Inherit Hibernatedaosupport class, use Hibernatetemplate to persist, Hibernatetemplate is
The lightweight package for Hibernate session
* The run-time exception is not rolled back by default (including inheriting the RuntimeException subclass), and normal exceptions are not rolled
* When writing a business logic method, it is best to throw an exception up and down in the presentation layer (Struts) processing
* About transaction boundary settings, usually set to the business layer, do not add to DAO


3. Understand several communication characteristics of transactions

1. propagation_required: If there is a transaction, the current transaction is supported. If no transaction is turned on

For example: In the Usermanager adduser in the open, then in the addlog when he will go to see if there is a use, so you can guarantee in the same business.

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 executes in a non-transactional manner and suspends any existing transactions.
6. Propagation_never: Always executes non-transacted 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, press the Transactiondefinition.propagation_required property to execute


4. The isolation level of spring transactions:The lower the level of super efficiency
1. Isolation_default: This is a platfromtransactionmanager default isolation level that uses the default transaction isolation level of the database. The other four correspond to the isolation level of JDBC
2. Isolation_read_uncommitted: This is the lowest isolation level of a transaction, which allows a foreign transaction to see the uncommitted data for this transaction. This isolation level produces dirty reads, non-repeatable reads, and Phantom reads.
3. Isolation_read_committed: Ensures that a transaction modified data is committed before it can be read by another transaction. Another transaction cannot read uncommitted data for the transaction
4. Isolation_repeatable_read: This transaction isolation level prevents dirty reads and cannot be read repeatedly. However, Phantom reads may occur. In addition to ensuring that one transaction cannot read uncommitted data from another transaction, it ensures that the following conditions are avoided (non-repeatable read).

5. isolation_serializable This is the most cost-effective, but most reliable, transaction isolation level. Transactions are processed for sequential execution. In addition to preventing dirty reading, non-repeatable reading, but also avoids phantom reading.

Several important APIs for hibernate support in spring:

Hibernatedaosupport realized an auxiliary DAO, he took out the session is also put into the threadlocal inside.
Gethibernatetemplate () This method is also possible.
There is a setsessionfactory () method in Hibernatedaosupport.

Spring Transaction Configuration