2017-08-21 1 views
2

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.

Antwort

0

Normalerweise sollten Thread-Pools (wie auch JDBC-Verbindungen) auf Unternehmensservern wie WebSphere nicht von einer Anwendung, sondern vom Server selbst verwaltet werden. Spring bietet nur eine Schnittstelle zwischen dem Threadpoolmodell Ihrer Anwendung und dem Server.

Der Hauptvorteil der Konfiguration von Thread-Pools auf der Serverseite ist die Effizienz: In früheren Zeiten wurden normalerweise mehrere Anwendungen auf demselben Server bereitgestellt. Mit Shared Thread Pool ist es möglich, alle Ressourcen des Servers zu nutzen. Heutzutage wird das Halten mehrerer Anwendungen auf demselben Java-Server als schlechte Praxis betrachtet (im Hinblick auf die Microservices-Architektur). Betrachten Sie daher solche Thread-Pools als Teil eines Legacy-Tech-Stacks.