With a nested transaction, a commit does not write any changes to disk, except for the top level transaction. A rollback, however works regardless of the level of the transaction, so yes, it will roll the inner transaction back.
It really all depends on your application architecture, in my opinion. It depends on how you are proxying your classes. If you have your app set to proxy-target-class=”true” (in your application context, then your @Transactional information wont be picked up if you annotate the Interface. Check out The Spring Docs — “Tips” for more information. … Read more
After doing some research, it seems I cannot have two connections opened to the same database with the TransactionScope block. I needed to modify my code to look like this: public void MyAddUpdateMethod() { using (TransactionScope Scope = new TransactionScope(TransactionScopeOption.RequiresNew)) { using(SQLServer Sql = new SQLServer(this.m_connstring)) { //do my first add update statement } //removed … Read more
See this link: PROPAGATION_NESTED versus PROPAGATION_REQUIRES_NEW? Juergen Hoeller explain it very well. — the Spring Source Forum is completely offline since February 28, 2019, but you can read the relevant part of the article in the quote below PROPAGATION_REQUIRES_NEW starts a new, independent “inner” transaction for the given scope. This transaction will be committed or … Read more
You commit. Period. There’s no other sensible alternative. If you started a transaction, you should close it. Committing releases any locks you may have had, and is equally sensible with ReadUncommitted or Serializable isolation levels. Relying on implicit rollback – while perhaps technically equivalent – is just poor form. If that hasn’t convinced you, just … Read more
Use the TransactionScope class like this: using (TransactionScope ts = new TransactionScope()) { //all db code here // if an error occurs jump out of the using block and it will dispose and rollback ts.Complete(); } The TransactionScope class will automatically convert to a distributed transaction if necessary.
Looking at your log I can instantly tell that your transaction settings are wrongly set. That’s because there’s no TransactionInterceptor call in your stack trace. The TransactionInterceptor is called by your Spring Service proxies when your web controllers call the actual Service methods. Make sure you use the Spring hibernate4 classes: org.springframework.orm.hibernate4.HibernateTransactionManager Don’t override @Transactional … Read more
Two answers: a) don’t do it. Use @Transactional in the service layer or the dao layer, but not both (the service layer is the usual choice, as you probably want one transaction per service method) b) if you do it, what happens depends on the propagation attribute of the @Transactional annotation and is described in … Read more
You need to extend transaction boundaries to the boundaries of your test method. You can do it by annotating your test method (or the whole test class) as @Transactional: @Test @Transactional public void testInsert(){ long id=myService.addPerson(“JUNIT”); assertNotNull(id); if(id<1){ fail(); } } You can also use this approach to ensure that data was correctly written before … Read more