Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Hibernate Transaction Autocommit set to false

 
Cj Recto
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys, I'm currently on learning about Spring integration with Hibernate, and so far I'm getting it to work. But I've run into situation where I dont want to commit the transaction at the end of process because I just want to see the generated sql stattement for testing and debugging purposes.

I have already added <prop key="hibernate.connection.autocommit">false</prop> to my hibernate properties, but then It still doesn't working.

Is it possible to achieve if using Spring to handle hibernate transaction? because in using traditional transaction in hibernate , it is possible, just don't call the session.commit() method and all the updates and insert will not be saved;


currently I have this code for service layer :




code for Dao layer :


But what happens here is that it does commit the transaction!, But I dont want to commit the transaction just for testing and debugging purposes.


I've also tried
@Transactional(propagation = Propagation.SUPPORTS, readOnly = false)
instead of
@Transactional(propagation = Propagation.SUPPORTS, readOnly = true)
But what happens here is that it does not commit the transaction, however the count of employee does not also incrementing.
So, what I am expecting to happen here is that count the number of employee before inserting to employee table. Then insert to employee table and count again the number of employee, so it would increment by 1. But at the end of the process , I don't want to commit that insert!

Do you have any Idea guys?

I would be very thankful for any help!
Thanks!



 
Bill Gorder
Bartender
Posts: 1682
7
Android IntelliJ IDE Linux Mac OS X Spring
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
all the extra qualifiers are not necessary for what you are doing. @Transactional by itself is sufficient. You may be setting auto commit to false but you are most certainly going to commit that data, because your method is transactional. That annotation will tell hibernate to commit when the transaction ends which in this case is when you reach the end of the method.


But I've run into situation where I dont want to commit the transaction at the end of process because I just want to see the generated sql stattement for testing and debugging purposes.


For what you are describing look at using DBUnit and creating an integration test case. If your really set on doing it this way though (and its just for seeing some sql and then your removing it), you can throw a runtime exception at the end of the method and it will roll back the transaction essentially having the same end result you are looking for although I would suggest this is an ugly way to be testing your code.

Thanks,
 
Ken Rimple
author
Ranch Hand
Posts: 63
Mac OS X Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bill Gorder wrote:
For what you are describing look at using DBUnit and creating an integration test case. If your really set on doing it this way though (and its just for seeing some sql and then your removing it), you can throw a runtime exception at the end of the method and it will roll back the transaction essentially having the same end result you are looking for although I would suggest this is an ugly way to be testing your code.


Also, with Spring @Test annotations, @ContextConfiguration (to provide the config file locations) and a @Transactional annotation, the default is to roll back. You can change that with @TransactionConfiguration which allows you to commit those changes in a test, but I wouldn't normally do that. The AbstractxxxTests base classes also provide this for JUnit 3.8, including a method to get your context, and settings you can apply to change the transactional intent. I forget them now but they are entirely do-able.

Ken
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic