Quadrix, mode=«aspectj» решит вопрос с вызовом транзакционного метода (@Transactional) в том же классе. Но не забываем про асинхронность, если уходить от использования TaskExecutor, то потребуется @Async, а для её обработки по-прежнему нужен dynamic proxy.
В целом смысл всего этого — дать варинт исполнения произвольного кода(не обязательно метода того же класса) асинхронно и в рамках транзакции. Т.е. посыл такой — если Вы используете TaskExecutor, но не хватает транзакционности, то статья даёт решение.
Async — да, используем, для методов вынесенных в отдельный бин (что-то наподобие job'ов), вызывать которые может понадобится в нескольких местах или по расписанию (например, используя @Schedule).
Вы это пробовали? Работает? Знали об этом способе?
Решений здесь 3:
1. вынести метод в отдельный класс;
Метод вынести можно, если это приемлемо для архитектуры (есть другой бин, в которм он будет смотреться гармонично). А что, если этот метод задумывался как правит? Или ещё часто бывает, что асинхронно нужно вызвать пару строк, которые в метод оформлять совсем не хочется.
2. через контекст получать proxy и вызывать на нем наш метод;
Когда-то разрабатывая EJB bean, я делал вот так:
@Stateless
public class FooServiceImpl implements FooService {
@EJB
private FooService fooService;
@TransactionAttribute
public void method1() {
// some operations
fooService.method2();
}
@TransactionAttribute
@Asynchronous
public void method2() {
// some high load operations
}
}
Выглядит как hook или workaround; не стал бы рекомендовать кому-либо так делать.
3. скомпилировать всё в AspectJ.
Тоже вариант. Однако, сделать универсальный Аспект, субъективно, сложнее чем унивесальный TaskExecutor.
@Async, а для её обработки по-прежнему нужен dynamic proxy.В целом смысл всего этого — дать варинт исполнения произвольного кода(не обязательно метода того же класса) асинхронно и в рамках транзакции. Т.е. посыл такой — если Вы используете TaskExecutor, но не хватает транзакционности, то статья даёт решение.
1) Это решение оправдавшее себя в проекте.
Метод вынести можно, если это приемлемо для архитектуры (есть другой бин, в которм он будет смотреться гармонично). А что, если этот метод задумывался как правит? Или ещё часто бывает, что асинхронно нужно вызвать пару строк, которые в метод оформлять совсем не хочется.
Когда-то разрабатывая EJB bean, я делал вот так:
Выглядит как hook или workaround; не стал бы рекомендовать кому-либо так делать.
Тоже вариант. Однако, сделать универсальный Аспект, субъективно, сложнее чем унивесальный TaskExecutor.