Doc: Inheritance of @Transactional and lookup behaviour of AbstractFallbackTransactionAttributeSource [SPR-12474]

[spring-projects-issues]

Ravi Sanwal opened SPR-12474 and commented

Lets start with a question to the expert.
Consider a service(or repo) bean

import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

/**
 * A service class with transactional method
 */
@Service
public class ServiceBean implements ServiceInterface {
    @Transactional
    public void serviceMethodA() {}
    public void serviceMethodB() {}
}

And a subclass of it

import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;


/**
 * Extended {@link ServiceBean}
 */
@Service
@Transactional
public class MagicalServiceBean extends ServiceBean {
}

Notice that only one method of ServiceBean is marked @Transactional while MagicalServiceBean has a class level @Transactional declaration.

What should be the transactional nature of method serviceMethodB when it is called on an injected (and proxied et al.) instance of MagicalServiceBean?

Apparently as per the apidocs of org.springframework.transaction.interceptor.AnnotationTransactionAttributeSource (org.springframework.transaction.interceptor.AbstractFallbackTransactionAttributeSource) we expect to get a transactional serviceMethodB.

Abstract implementation of TransactionAttributeSource that caches attributes for methods and implements a fallback policy: 1. specific target method; 2.target class; 3. declaring method; 4. declaring class/interface.

A specific distinction is mentioned between target class and declaring class/interface

Codewise if we look at org.springframework.transaction.interceptor.AbstractFallbackTransactionAttributeSource.getTransactionAttribute(Method, Class<?>), the targetClass parameter points to MagicalServiceBean.class.

You may consider it as a documentation defect.
There could be arguments for both "should apply transactional on extended method"(because this seems more intuitive and correct) and "should not apply on extended method"(to keep it the way base class has defined and because we can always create a delegate method on the extended class if we need to make it transactional)

Regardless this seems to be an odd behavior to me.

---

Affects: 4.1.2

[spring-projects-issues]

Ravi Sanwal commented

So, is it really a documentation thing? Would you, if possible, share your thoughts about it?
It is pretty common pattern to have generic data access classes having create/update/delete/find methods concretely defined in an abstract super class, and then extend it for specific (JPA) entities with (possibly) more finders etc. in it.
It is really awkward to delegate these methods in every sub class.
We do have use cases where these kind of base classes with generic methods are used with different transaction managers.

[spring-projects-issues]

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.