i have a class that has a @Transactional on the class itself. It inherits from a base class. The base class implements an interface with methods on it and has a public methods in it.

@Transactional@ServiceclassFooServiceextendsBaseService \{ }

My expectation is that the public methods in BaseService should be demarcated in a transaction. If I do nothing but override the methods and then call the super implementation, things work as expected.

If you remove the 3 methods, findById, save, and findAll, they are still public methods in BaseCustomerService. I have a test that tests that i can write data to the DB and see it roll back. the test fails if i have removed those methods. it succeeds when i add them.

This comment has been minimized.

It looks to me like the logic in AbstractFallbackTransactionAttributeSource.computeTransactionAttribute() simply never took this scenario into account: someone annotates TransactionalCustomerService as @Transactional but all the methods are declared in a base class. The Method that is analyzed doesn't have the @Transactional annotation and neither does its declaring class, but the bean class does.

This comment has been minimized.

This is by design: A class-level transactional demarcation only applies to the methods as per its level in the inheritance hierarchy. Redeclaring methods at that level is exactly what it takes to include them in such a class-level transactional demarcation, or of course locally annotating the redeclared methods themselves. This allows for fine-tuning the scope of the transactional demarcation through putting methods at the appropriate place in the inheritance hierarchy.