In Hibernate, every time we do an operation, we are going to start the transaction, then do the data operation, then commit the transaction, close the transaction, the reason is because
Hibernate default Transaction autocommit is False, it is necessary to manually commit the transaction, and if you do not want to commit the transaction manually every time, you can
Hibernate.cfg.xmlSet it as transaction autocommit in my file:
< PropertyName = "Hibernate.connection.autocommit" >true</Property>
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 can manipulate the data directly using the data manipulation methods provided by this class. We also don't see the code for the transaction.
does spring actually encapsulate transactions 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 1. If in the process of integration, If we discard the Hibernate.cfg.xml file and configure the data source directly in the spring configuration file, the method you provide directly in the hibernatetemplate is
can succeedManipulate the data. 2. If you are using Hibernate.cfg.xml to configure the data source, reference the Hibernate.cfg.xml file in the spring configuration file,
then you can't succeed ., the reason for this is that if you use the 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:
<name= "Defaultautocommit"><value> false</value></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, the consistency of the guaranteed data, either all succeed or fail, and we can't save a piece of data every timeThe
transaction is automatically submitted, because they are not in the same transaction, and we cannot guarantee that the data will be consistent. 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.
Just a little bit about spring's food. For more information and to use view spring's things management posts
declarative transaction configuration is mainly divided into the following steps:
1. Declarative transaction Configuration(1) Configure the transaction manager; (2) The propagation characteristics of the transaction; (3) 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:pointcutID= "Allservicemethod"expression= "Execution (* com.coe.service.*.* (..))"/> <Aop:advisorPointcut-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 methodsAt 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.
1234567. 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 session effective period (object submission management) Introduction