@Transactional inheritance [SPR-7180]

[spring-projects-issues]

David Cole opened SPR-7180 and commented

For large projects, with a lot of transactional aware objects, it seems useful to define the @Transactional semantics at the class level, and override the settings at the method level as necessary. Consider the following example:

@Transactional(propagation = Propagation.REQUIRED, rollbackFor = MyException.class, timeout = 600)
public class DefaultFooService implements FooService {

  public Foo getFoo(String fooName) {
    // do something
  }

  // these settings have precedence for this method
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void updateFoo(Foo foo) {
    // do something
  }
}

At the class level, we have defined what we hoped would be the defaults for all methods within the class. For the method updateFoo(), we need to change the propagation level to REQUIRES_NEW, but want to re-use the defaults that have already been specified at the class level. So we added the @Transactional meta-data on the method. Once we have added just the propagation level to the method, we lose rollbackFor and timeout properties set at the class level - there is no form of inheritance.

As a result, you must include all additional properties again on the method, the properties defined at the class level are completely ignored. The result of this is that we have to redundantly copy the properties onto the @Transactional declaration for every method from the class in order to retain them, which is unfortunate.

What we were hoping for, was to be able to simply change the rollbackFor by appending an additional Exception at the class level and have all methods, only those with the @Transactional annotation that did not explicitly set the rollbackFor property, benefit from the change via inheritance. Instead, we would have to go back and systematically add the change to every method explicitly, instead of simply appending it to the rollbackFor property of the @Transactional annotation at the class level.

I can see that maybe this could introduce some problems with backwards compatibility. So, maybe Spring could introduce an additional property on the @Transactional annotation like: 'inherit=true', which would then signal that any unset properties should be inherited from the next higher level. So, if the method set the inherit=true property, then it should inherit any unset properties from the class. If the class has not set a property, then it would inherit from the TransactionManager defaults as expected.

---

Affects: 3.0 GA

2 votes, 4 watchers

[spring-projects-issues]

Jonas commented

I find this unclear in the documentation. I already thought it worked like this.

[spring-projects-issues]

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

[elab]

Priority of the annotations (annotation on a method always has a higher priority than an annotation on the class) is OK. But what we should think about, is merging of the annotation parameters. I proposed a concrete change how to do that in #24291. Currently, there is no merging in Spring, it works like David (@MoJava) described.