Ich arbeite an einer Java-Anwendung. Wir verwenden Spring und die Anwendung führt WebSphere Application Server aus. In der gesamten App verwalten wir mehrere Thread-Pools, die in der Anwendung mithilfe von Spring erstellt werden. Wie unten und bisher hatten wir keine Probleme damit.Java-Anwendung Thread-Erstellung
<bean id="taskExecutor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
<property name="maxPoolSize" value="100"/>
<property name="corePoolSize" value="10"/>
</bean>
Aber ich war Referenz Spring-Framework-Dokumentation zu lesen, wo ich über den Absatz unten kam,
34.3.3 Taskscheduler Implementierungen
Wie bei TaskExecutor Abstraktion Frühling, der Hauptvorteil von Der TaskScheduler ist, dass Code, der auf Planungsverhalten angewiesen ist, nicht an eine bestimmte Scheduler-Implementierung gekoppelt sein muss. Die Flexibilität, die diese bietet, ist besonders relevant, wenn sie in der Anwendung Serverumgebungen ausgeführt wird, in denen Threads nicht direkt von der Anwendung selbst erstellt werden sollen. In solchen Fällen stellt Spring einen TimerManagerTaskScheduler bereit, der an eine CommonJ TimerManager-Instanz delegiert, die normalerweise mit einem JNDI-Lookup konfiguriert ist.
ref. https://docs.spring.io/spring/docs/current/spring-framework-reference/html/scheduling.html
so meine Frage ist, wenn ich keinen Zugriff auf Java EE Kontextinformationen ist es egal, haben, was andere Gründe gibt es geschafft, verwenden Thread-Pools? Ich frage mich im Grunde, was ist die beste Praxis da draußen und wenn Application Thread verwaltet ist völlig inakzeptabel.