I am working on a java application. We're using Spring and the application runs WebSphere application server. Throughout the app, we maintain multiple thread pools that are created within application using Spring. Like below and so far we haven't had any issues with this.
<bean id="taskExecutor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
<property name="maxPoolSize" value="100"/>
<property name="corePoolSize" value="10"/>
</bean>
But I was reading Spring framework reference docs where I came across the paragraph below,
34.3.3 TaskScheduler implementations
As with Spring’s TaskExecutor abstraction, the primary benefit of the TaskScheduler is that code relying on scheduling behavior need not be coupled to a particular scheduler implementation. The flexibility this provides is particularly relevant when running within Application Server environments where threads should not be created directly by the application itself. For such cases, Spring provides a TimerManagerTaskScheduler that delegates to a CommonJ TimerManager instance, typically configured with a JNDI-lookup.
ref. https://docs.spring.io/spring/docs/current/spring-framework-reference/html/scheduling.html
so my question is if I don't care to have access to Java EE contextual information, what other reasons are there to use managed thread pools? I'm basically wondering what is the best practice out there and if having application managed thread is totally unacceptable.
Typically, thread pools (as well as JDBC connections) on enterprise servers like WebSphere should not be managed by an application but by the server itself. Spring provides only an interface between your application and server's thread pool model.
Main benefit of configuring thread pools on server's side is efficiency: in old times several applications were deployed to the same server usually. With shared thread pool it's possible to utilize all resources of the server. Nowadays, keeping several applications on the same Java server is considered as bad practice (in the light of microservices architecture). So just consider such thread pools as a part of legacy tech stack.