I am migrating from iBatis 2.3 to MyBatis 3.2.8. Everything is going well, but I do have a question when it comes to transactions and batch operations. Towards the bottom of https://mybatis.github.io/spring/sqlsession.html, it says:
The caveat to this form is that there cannot be an existing transaction running >with a different ExecutorType when this method is called. Either ensure that >calls to SqlSessionTemplates with different executor types run in a separate >transaction (e.g. with PROPAGATION_REQUIRES_NEW) or completely outside of a >transaction.
I have a service call that is annotated with #Transactional that makes multiple Dao Calls:
#Override
#Transactional
public void saveMassUploadOrder(List<IndividualOrder> orders) {
List<IndividualOrderItem> ioItems = new ArrayList<IndividualOrderItem>();
for (IndividualOrder order : orders) {
ioItems.addAll(order.getIoItems());
}
individualOrderDao.insertBatch(orders);
individualOrderItemDao.insertBatch(ioItems);
}
The DAOs would look like:
public class IndividualOrderDAOImpl implements IndividualOrderDAO{
private SqlSession sqlSession;
public void setSqlSession(SqlSession sqlSession) {
this.sqlSession = sqlSession;
}
public void insertBatch(final List<IndividualOrder> orders) {
for (IndividualOrder order: orders){
sqlSession.insert("namespace.insert", order);
}
}
}
The config looks like:
<bean id="batchSqlSession" class="org.mybatis.spring.SqlSessionTemplate">
<constructor-arg index="0" ref="doeSqlSessionFactory" />
<constructor-arg index="1" value="BATCH" />
</bean>
<bean id="individualOrderDao" class="com.doe.mybatis.jdoe.dao.IndividualOrderDAOImpl">
<property name="sqlSession" ref="batchSqlSession" />
</bean>
<bean id="individualOrderItemDao" class="com.doe.mybatis.jdoe.dao.IndividualOrderItemDAOImpl">
<property name="sqlSession" ref="batchSqlSession" />
</bean>
So - would the multiple DAO calls within this service call be OK since the service is opening a transaction and its not working in a batch mode and making calls to these DAOs? Obviously, I am wanting the call to this service to not actually insert any orders or order items if there is a failure somewhere during the execution.
I haven't migrated these DAOs yet, and I can probably set up a catastrophic event during a test batch insert and check the data, I was just wanting to get some other opinions before I started to see if I have to set this up differently or not.
Any help appreciated!
Related
Assuming I have the next code:
#Autowired
private IManager1 manager1;
#Autowired
private IManager2 manager2;
#Autowired
private IManager3 manager3;
#Transactional
public void run() {
manager1.doStuff();
manager2.registerStuffDone();
manager3.doStuff();
manager2.registerStuffDone();
manager1.doMoreStuff();
manager2.registerStuffDone();
}
If any exception is launched I want to rollback everything done by the "doStuff()" methods, but I don't want to rollback the data recorded by the "registerStuffDone()" method.
I've been reading the propagation options for #Transactional annotation, but I don't understand how to use them properly.
Every manager internally uses hiberante to commit the changes:
#Autowired
private IManager1Dao manager1Dao;
#Transactional
public void doStuff() {
manager1Dao.doStuff();
}
Where the dao looks like this:
#PersistenceContext
protected EntityManager entityManager;
public void doStuff() {
MyObject whatever = doThings();
entityManager.merge(whatever);
}
This is my applicationContext configuration:
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="dataSourcePool" />
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter"/>
</property>
</bean>
<bean id="entityManager" class="org.springframework.orm.jpa.support.SharedEntityManagerBean">
<property name="entityManagerFactory" ref="entityManagerFactory" />
</bean>
<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory" />
</bean>
<tx:annotation-driven transaction-manager="transactionManager"/>
Ideas?
You need 2 transactions, one for the stuff to be committed and one for the stuff to be rolled back.
#Transactional(propagation = Propagation.REQUIRES_NEW, noRollbackFor={Exception1.class, Exception2.class})
public void registerStuffDone()() {
//code
}
Your run method will then use the first transaction and that will be rolled back, but the registerStuffDone method will start a second transaction which will be commited.
You are using declarative transaction and want to control like program sense. For this reason, you need more practice and deep understanding about Spring transaction definition such as PROPAGATION, ISOLATION etc...
Programmatic transaction management: This means that you have manage the transaction with the help of programming. That gives you extreme flexibility, but it is difficult to maintain.
VsDeclarative transaction management: This means you separate transaction management from the business code. You only use annotations or XML based configuration to manage the transactions.
Perhaps, alternative way for your questions by Programmatic transaction management.
/** DataSourceTransactionManager */
#Autowired
private PlatformTransactionManager txManager;
public void run() {
try {
// Start a manual transaction.
TransactionStatus status = getTransactionStatus();
manager1.doStuff();
manager2.registerStuffDone();
manager3.doStuff();
manager2.registerStuffDone();
manager1.doMoreStuff();
manager2.registerStuffDone();
//your condition
txManager.commit(status);
//your condition
txManager.rollback(status);
} catch (YourException e) {
}
}
/**
* getTransactionStatus
*
* #return TransactionStatus
*/
private TransactionStatus getTransactionStatus() {
DefaultTransactionDefinition dtd = new DefaultTransactionDefinition();
dtd.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW);
dtd.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED);
dtd.setReadOnly(false);
return txManager.getTransaction(dtd);
}
Note: It does not mean you need to always use one approach like Programmatic transaction management. I prefer mixed approach. Please use easy way like Declarative transaction for simple database services, otherwise, just control with Programmatic transaction in your services will save your logic easily.
I have Spring 4 with Hibernate 4. My problem is that I want to have transaction on imported data. I parse JSON and next store it to DB. But when something will go wrong (server will go down). I don't want to have part of data in DB.
I have method:
#Transactional
private void processJson()
in which I call in loop:
recipientGroupSellInService.saveOrUpdate(perDay);
it looks much like this:
#Transactional
private void processJson(){
for(int i : iSet){
recipientGroupSellInService.saveOrUpdate(perDay[i]);
}
}
save or update:
#Transactional
public Boolean saveOrUpdate(T model) {
getSession().saveOrUpdate(model);
return true;
}
so after calling saveOrUpdate data is stored to DB, and not roll back on general failure of method processJson.
What should I look after or change to have "real transaction" on method processJson?
The transaction is started in processJson(). Since your saveOrUpdate() is using the regular #Transactional, it will join the previously started transaction.
If there is a problem (i.e. a RuntimeException), anything made by or from processJson() will be rolled back.
Are you claiming that you're seeing behaviour where partial data is written?
Have you configured the PlatformTransactionManager? (either from xml or from Configuration)
Eg:
<bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource"/>
</bean>
I just have a new project to maintain, and using Hibernate+Spring. I wrote a DeliveryInfoServiceImpl which have a method to query for some entity but not have any update or save operation, but I have an error:
Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here
Unless I add #Transactional on the method or the class.
My questions are :
Why I have to add #Transactional though I am only executing select query?
Does adding #Transactional means enable transaction support ,which may have more unnecessary overhead when I am only using "select" query.
Below is my code snippet:
#Override
public List<UnavailableRestaurantBean> getUnavailableRestaurantBean(String custAddress, List<Long> dishesId) {
List<Dish> dishes = getDishByIds(dishesId);//exception here
....
}
private List<Dish> getDishByIds(List<Long> ids){
return deliveryInfoDao.findByIds(Dish.class,ids);
}
And I have below transaction manager config:
<tx:annotation-driven transaction-manager="myTxManager" />
<bean id="myTxManager" name="transactionManager"
class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<property name="sessionFactory" ref="mySessionFactory">
</property>
</bean>
I need to call some method after transaction succes or rollback. I am using as
<bean name="openSessionInViewInterceptor" class="org.springframework.orm.hibernate3.support.OpenSessionInViewInterceptor">
<property name="sessionFactory">
<ref local="mysessionFactory"/>
</property>
</bean>
<bean id="txManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<property name="sessionFactory">
<ref local="mysessionFactory"/>
</property>
</bean>
<tx:annotation-driven transaction-manager="txManager" proxy-target-class="true"/>
The application use some external web services which needs to be "cleaned" when the internal transaction gets rollbacked.
Is there way how to accomplish this without using declarative transaction management.
From Hibernate, you could extends EmptyInterceptor and override
afterTransactionCompletion() method and register it in
SessionFactoryBean or HibernateTransactionManager.
From Spring you could extends TransactionSynchronizationAdapter and
override afterCompletion() and register when appropriate with
TransactionSynchronizationManager#registerSynchronization().
Edit
An Example of using Spring Aop to add a synchronization to all methods annotated with #Transactional
#Aspect
class TransactionAspect extends TransactionSynchronizationAdapter {
#Before("#annotation(org.springframework.transaction.annotation.Transactional)")
public void registerTransactionSyncrhonization() {
TransactionSynchronizationManager.registerSynchronization(this);
}
#Override
public void afterCompletion(int status) {
// code
}
}
Spring has various classes which might be of interest here:
http://docs.spring.io/spring/docs/3.2.x/javadoc-api/org/springframework/transaction/support/TransactionSynchronization.html
http://docs.spring.io/spring/docs/3.2.x/javadoc-api/org/springframework/transaction/support/TransactionSynchronizationAdapter.html
http://docs.spring.io/spring/docs/3.2.x/javadoc-api/org/springframework/transaction/support/TransactionSynchronizationManager.html
There's some example code here:
http://azagorneanu.blogspot.co.uk/2013/06/transaction-synchronization-callbacks.html
Update 2016
The event handling infrastructure introduced in Spring 4.2 makes this much simpler.
See:
https://spring.io/blog/2015/02/11/better-application-events-in-spring-framework-4-2#transaction-bound-events
Another popular improvement is the ability to bind the listener of an
event to a phase of the transaction. The typical example is to handle
the event when the transaction has completed successfully
#Component
public class MyComponent {
#TransactionalEventListener(condition = "#creationEvent.awesome")
public void handleOrderCreatedEvent(CreationEvent<Order> creationEvent) {
...
}
}
#TransactionalEventListener is a regular #EventListener and also
exposes a TransactionPhase, the default being AFTER_COMMIT. You can
also hook other phases of the transaction (BEFORE_COMMIT,
AFTER_ROLLBACK and AFTER_COMPLETION that is just an alias for
AFTER_COMMIT and AFTER_ROLLBACK).
Using Spring 4+: The easiest/cleanest way without using global aspects and configurations is based on my answer here: https://stackoverflow.com/a/43322052/986160
If you need a callback on a #Transactional method after it successfully commits just add that in the beginning of the method:
#Service
public class OneService {
#Autowired
OneDao dao;
#Transactional
public void a transactionalMethod() {
TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronizationAdapter(){
public void afterCommit(){
//do stuff right after commit
System.out.println("commit!!!");
}
});
//do db stuff
dao.save();
}
}
My application is based on Hibernate 3.2 and Spring 2.5. Here is the transaction management related snippet from the application context:
<tx:annotation-driven transaction-manager="txManager"/>
<bean id="txManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<property name="sessionFactory" ref="sessionFactory"/>
<property name="nestedTransactionAllowed" value="true"/>
</bean>
<bean id="transactionTemplate" classs="org.springframework.transaction.support.TransactionTemplate">
<property name="transactionManager" ref="txManager"/>
</bean>
<bean class="org.springframework.beans.factory.annotation.RequiredAnnotationBeanPostProcessor"/>
<bean id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
<property name="configLocation" value="classpath:/hibernate.cfg.xml"></property>
</bean>
For all the DAO's there are relevant Service class and the transactions are handled there using #Transactional on each method in the service layer. However there is a scenario now that a method in DAO say "parse()" is called from the service layer. In the service layer I specified #Transactional(readOnly=false). This parse method in the DAO calls another method say "save()" in the same DAO which stores a large number of rows (around 5000) in the database. Now the save method is called in a loop from the parse function. Now the issue is that after around 100 calls to the "save" method.. i sometimes get a OutOfMemory Exception or sometimes the program stops responding.
For now these are the changes which I have made to the save method:
Session session = getHibernateTemplate().getSessionFactory().openSession();
Transaction tx = session.beginTransaction();
int counter = 0;
if(books!=null && !books.isEmpty()){
for (Iterator iterator = books.iterator(); iterator
.hasNext();) {
Book book = (Book) iterator.next();
session.save(book);
counter++;
if(counter % 20==0) {
session.flush();
session.clear();
}
}
}
tx.commit();
session.close();
This is the only method in my application where I start a transaction like this and commit it at the end of method. Otherwise I normally just call getHibernateTemplate.save(). I am not sure whether I should perform transaction management for this save method separately in the DAO by placing #Transactional(readOnly=false, PROPOGATION=NEW) on save(), or is this approach okay?
Also I have updated the hibernate.jdbc.batch_size to 20 in the hibernate.cfg configuration file.
Any suggestions?
For the batch insertion with hibernate, the best practice is StatelessSession, it doesn`t cache any states of your entity, you will not encounter OutOfMemory, the code like:
if (books == null || books.isEmpty) {
return;
}
StatelessSession session = getHibernateTemplate().getSessionFactory().openStatelessSession();
Transaction tx = session.beginTransaction();
for (Book each : books) {
session.insert(book);
}
tx.commit();
session.close();
And the Transaction of StatelessSession is independent from the current transaction context.
You only need the bit with flushing and clearing the session. Leave transaction management to Spring. Use sessionFactory.getCurrentSession() to reach the session that Spring has already opened for you. Also, Spring's recent recommmendation is to avoid HibernateTemplate and work directly with Hibernate's API. Inject SessionFactory to your dao-bean.
I would refactor parse in a way it doesn't call save directly but takes some callback from service layer. Service layer would pass its transactional method with save call as this callback.
It may not work exactly as decribed in your case but from this short description this would be something I'd try.