0

I'm trying to figure out what is the best way for solving the issue with @Transactional and private/protected methods, as described here: Does Spring @Transactional attribute work on a private method?

In the question above, most of the replies recommended aspectJ, but there are also other alternatives, such as delegation or auto wiring or using Java 8's lambdas as explained here: https://dzone.com/articles/spring-transactional-and-private-methods-snippet

Taking into account that I'm trying to make changes in an existing vast project, what do you think is the best solution? If it is aspectJ, load time or compile time weaving?

Koren Lazar
  • 1
  • Welcome to SO. Please note that primarily opinion-based questions are considered off-topic here. As for AspectJ in connection with Spring, the [LTW approach](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-using-aspectj) is the best documented and it would not require you to change your build setup. OTOH it requires you to add a Java agent to the command line, which CTW does not. Your choice. Also ask yourself if the need to add transactional behaviour to private methods is not a code smell and maybe you should refactor. I warmly recommend the latter. – kriegaex May 21 '19 at 01:12
  • Thank you for the response! I will take the opinion-based note into account in future questions. May you clarify what exactly is the code smell in adding transactional behaviour to private methods? – Koren Lazar May 21 '19 at 08:12
  • Yes, I can: I believe that whatever cross-cutting concerns (transactions, remoting, logging etc.) you apply to your code base should be applied on the level of your public API. If applying cross-cutting behaviour requires you to have knowledge of private methods, the granularity of your API is probably wrong and you need to refactor in order to fix it. Either the corresponding private methods should be public or the transactionality is applied on the wrong level. – kriegaex May 21 '19 at 08:39
  • See? We are having an opinionated meta discussion already, as I said. I am stepping the the trap myself because you provide no code to analyse and reason about. This is why the question in its current form is not suited for SO. – kriegaex May 21 '19 at 08:42

0 Answers0