Spring ThreadPoolTaskExecutor в веб-приложении Tomcat -плохая практика?

Недавно в моем проекте у меня возникла необходимость выполнять некоторые задачи асинхронно.Поскольку мы запускаем веб-приложение с Spring внутри Tomcat, ThreadPoolTaskExecutor, предоставленный Spring, был решением.

Однако архитектор выдвинул некоторые возражения, заявив, что ужасно/запрещено/абсолютно зло создавать потоки/иметь пул потоков в веб-приложении.

Немного поискав в сети и на StackOverflow, я понял, что да, иметь собственный пул потоков внутри контейнера Java EE — плохая практика. Обоснование заключалось в том, что если у вас есть собственный пул потоков, контейнер не знает об этом и не может правильно управлять ресурсами. Это особенно важно, когда вам нужно выполнить несколько горячих развертываний вашего веб-приложения.

Теперь наш вариант использования — веб-приложение Spring, запущенное внутри Tomcat. Во-первых, можем ли мы рассматривать контейнер Spring как легкий контейнер Java EE ? В этом случае именно Spring управляет жизненным циклом пула потоков, а не само приложение, не так ли?

Во-вторых, применим ли аргумент горячего развертывания для этой конфигурации?

И да, я знаю, что можно объявить рабочий пул прямо в Tomcat и внедрить его через JNDI в Spring. Но это немного хлопотно по сравнению с прямым средством ThreadPoolTaskExecutor, предоставляемым Spring

. Итак, мой последний вопрос::уместно ли возражение архитектора в моем случае?

Спасибо за ваши предложения и мысли по этой теме.