How to configure which transaction manager to use without overriding all @Transactional methods

Question

Average wait time for the first listener.

We have an AbstractService.java class that contains common transaction logic. Not all methods in this class are transactional. The one that is is annotated with the annotation spring @Transactional.

Now, each AbstractService implementation could potentially have a different transaction manager. You can configure this in a specific class by overriding the method in the abstract class and providing another tx manager:

@Transactional (value = TRANSACTION_MANAGER)

It is not possible to pass the name of the transaction manager to the abstract class because "The value of the Transactional.value annotation attribute must be a constant expression."

So, as far as I know, there are two ways to set up a transaction manager:

• Override each @Transactional method in a particular class only to call the super method:

  @Transactional(timeout = 60, value = TRANSACTION_MANAGER) @Override public String editEntity(Integer id, Integer columnPosition, Object value) { return super.editEntity(id, columnPosition, value); 

• Add an @Transactional annotation at the class level instead. This forces us to process non-transactional methods as part of the transaction, and since non-transactional methods call other methods that are transactional, we end up with a nested tx soup.

Is there a third option? Something like outdated spring testing @NotTransactional would do the trick along with option 2 above.

There was a very similar question asked almost three years ago. Since a lot has happened to spring, have we got another option since then?

Although this question is inactive, the custom annotation answer does not affect the question.

My question can be summarized:

How do I set up transactions without having to override ALL transactional methods just to specify a transaction manager?

Answer 1

I suggest you reorganize AbstractService into three classes:

• The first class is the current AbstractService , its interface, method signatures, etc., to remain binary, compatible with any existing child classes, but the entire implementation has been removed.
• The second class contains all the business logic, which is transactional, and therefore it uses the @Transactional annotation (with the right class-level transaction manager).
• The third class contains all non-transactional business logic.

Now you simply create the last two classes in the refactored AbstractService , which simply delegates the incoming call to the implementation method that has been moved to one of the newly created classes.