How do you refactor a @Transactional method to split out non-transactional parts

Question

I have a data access class which runs as part of a stand-alone java application. It is currently working which means that a transaction manager is defined but I want to refactor the class to reduce the scope of the transaction but if I do I get org.hibernate.HibernateException: No Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here which implies that moving the @Transactional has somehow stopped it from being recognised.

My original version had the refactored methods being private but I found a recommendation to change that to public as in some cases the annotation would not be picked up.

public class DoStuff {
    @Transactional
    public void originalMethod() {
        // do database stuff
        ...

        // do non-database stuff that is time consuming
        ...
    }
}

What I want to do is refactor to the following

public class DoStuff {
    public void originalMethod() {
        doDatabaseStuff()

        doNonDatabaseStuff()
    }

    @Transactional
    public void doDatabaseStuff() {
        ...
    }

    public void doNonDatabaseStuff() {
        ...
    }
}

Where is your transaction-manager ? Can you add more details ? — Chris, Aug 23 '12 at 11:09
No interfaces, and the transaction manager is defined as it works for the original class. — Michael Rutherfurd, Aug 23 '12 at 21:47

gresdiplitude · Accepted Answer · 2012-08-24T07:30:40.947

Edit:

You need to understand how Spring proxying works to understand why your refactoring does not work.

Method calls on the object reference will be calls on the proxy, and as such the proxy will be able to delegate to all of the interceptors (advice) that are relevant to that particular method call. However, once the call has finally reached the target object, any method calls that it may make on itself, are going to be invoked against the this reference, and not the proxy. This has important implications. It means that self-invocation is not going to result in the advice associated with a method invocation getting a chance to execute.

@Transactional uses Spring AOP, Spring uses proxies. This means that when you call an @Transactional method from another class, Spring will use a proxy, so the transactional advice will be applied. However, if you call the method from the same class, spring will use the "this" reference instead of the proxy, so that transactional advice will not be applied.

Original Answer:

Here is what worked for me in similar scenario.

public class DoStuff implement ApplicationContextAware {    
private ApplicationContext CONTEXT;
public void setApplicationContext(ApplicationContext context) throws BeansException {
    CONTEXT = context;
}

    public void originalMethod() {           
        getSpringProxy().doDatabaseStuff()              
        doNonDatabaseStuff()       
    }

    private DoStuff getSpringProxy() {
        return context.getBean(this.getClass());     
    } 
    @Transactional       
    public void doDatabaseStuff() {           
        ...       
    }          

    public void doNonDatabaseStuff() {           
        ...       
    }   
}

Explanation:

Make the class ApplicationContextAware, so it has a reference to the context
When you need to call a transactional method, fetch the actual spring proxy from the context
Use this proxy to call your method, so that @Transactional is actually applied.

The original class already recognises @Transactional and works correctly. It only stops working after refactoring. — Michael Rutherfurd, Aug 23 '12 at 21:45

score 0 · Answer 2 · answered Aug 23 '12 at 19:08

0

Your approach looks like it should work just fine, I expect the issue is related to Spring proxies.

The reason that I asked about interfaces is related to the default method by which Spring applies transactional behaviour - JDK dynamic proxies.

If the actual definition of your class is:

public class DoStuff implements Doable {
  public void originalMethod() {

  }
}

public interface Doable {
  public void originalMethod();
}

If this is indeed the structure, when you moved to the new structure Spring is not able to proxy the new doDatabaseStuff method.

Your options to fix this:

Add the new methods to your interface to ensure that Spring can proxy them
Move to using CGLIB based proxies (these do not rely on interfaces)

answered Aug 23 '12 at 19:08

Alex Barnes

7,174
1
30
50

No the class is a POJO, no interfaces implemented at all – Michael Rutherfurd Aug 23 '12 at 21:43
Oh well. Still. It's all true :) – Alex Barnes Aug 23 '12 at 22:45
I wasn't disagreeing I( was just saying it didn't apply in this case :-) – Michael Rutherfurd Aug 24 '12 at 00:28

How do you refactor a @Transactional method to split out non-transactional parts

2 Answers2