On upgrading from Spring 6.2.11 to 6.2.13, we found that in some cases, transactions are not being created when calling methods with Transactional annotations where with 6.2.11, they were. For example, we have a case where a method is annotated with Transactional(readOnly = true, propagation = Propagation.REQUIRED), but when called with no transaction already active, it does not create one.

This seems to be due to the changes for #35780, namely 6f81cb6 and 38555df. The particular change that is causing our version of the problem is in AbstractFallbackTransactionAttributeSource.java's computeTransactionAttribute method. We have a class that has a method with the above annotation, where that method is implementing an interface method. Also, that interface extends BeanNameAware and the class implements BeanNameAware's setBeanName method so that it can have the bean name available.

At runtime, computeTransactionAttribute gets called with a method whose getDeclaringClass() is the interface and with the implementation class as targetClass. This runs into the new lines of code added in these changes:

    // Skip methods declared on BeanFactoryAware and co.
    if (method.getDeclaringClass().isInterface() && Aware.class.isAssignableFrom(method.getDeclaringClass())) {
        return null;
    }

Both conditions are true, and so computeTransactionAttribute returns null instead of a TransactionAttribute based on the Transactional annotation. Previously, in 6.2.11, it would execute the next line that uses AOPUtils.getMostSpecificMethod, and proceed to find and return the desired transaction attribute.

The combination of classes that happen to implement BeanNameAware and that implement interface methods with a method that has a Transactional annotation are not uncommon in our code. I'm not sure what the intent of returning null was in this case, but it is far too broad of a condition and makes 6.2.13 unusable for us (we had been eager to use some of the PathPattern matching enhancements in it).

There were very obvious symptoms for us in this case, but there may be other similar problems, since the same lines of code were introduced in other AbstractFallback* classes at the same time.