J(2)ee, die Grundlagen und mehr

In dieser Serie möchte ich einige Themen ansprechen, die zwar alt und bekannt sind, aber Entwickler und Administratoren in einer j2ee-Umgebung immer noch zu verwirren scheinen. Denken Sie an alles in oder um einen Anwendungsserver herum. Wenn ich von Anwendungsservern spreche, beziehe ich mich meistens auf Websphere. Leider habe ich keine wirkliche Erfahrung mit anderen Servern. Dennoch möchte ich eine breite Perspektive einnehmen und das Publikum nicht einschränken. Das Niveau sollte Anfänger bis Fortgeschrittene sein. Teil1 Starten Sie Ihre eigenen Threads. Solange ich mit Anwendungsservern gearbeitet habe, hat man mir immer gesagt, ich solle keine eigenen Threads starten, da dies laut j2ee-Spezifikation verboten sei. Diese Threads werden auch als 'naked' und 'unmanaged' bezeichnet. Die Gefahr, die von ihnen ausgeht, ist, dass sie Dinge tun, von denen der Anwendungsserver nichts weiß. Das kann zu Ressourcenverlusten, fehlendem Debugging, dem Ausfall eines Servers oder zu Sicherheitsproblemen führen. Dennoch gibt es eine Reihe von Open-Source-Frameworks, die genau das tun, und niemand scheint etwas dagegen zu haben. Denken Sie an Quarz oder Log4j (der Watchdog, der Änderungen in den Log4j-Einstellungen überwacht). Und sogar das jdk selbst ist schuldig: Die Verwendung von java.util.Timer führt ebenfalls zu so genannten unmanaged Threads.

Und bis jetzt haben die mir bekannten Anwendungsserver auch keine Einwände erhoben. Die Anwendungen konnten also tatsächlich spawnen, was immer sie wollten, und kamen damit durch. Es gab auch einen Grund, diese Situation nicht zu ändern. Die Art und Weise, wie es funktionierte, machte die Anwendung von den Interna des Anwendungsservers abhängig. Im Fall von Websphere wird die Methode von IBM vollständig unterstützt und hat sich beispielsweise in Websphere 6 nicht geändert; dennoch zögern die Entwickler, Software zu entwickeln, die nicht auf anderen Anwendungsservern läuft. Das macht die Migration sicherlich einfacher. Ein Nachteil (der Erstellung eigener Threads) ist, dass Sie auf sich allein gestellt sind, wenn es um Transaktionsmanagement und Gleichzeitigkeitskontrolle geht.So funktionierte es:implementieren Sie com.ibm.websphere.asynchbeans.Work, beziehen Sie einen Workmanager von jndi und übergeben Sie die Klasse Work an den Manager.Seit einiger Zeit gibt es commonj. Dabei handelt es sich um eine Reihe von Schnittstellen, die von j2ee-Anbietern implementiert werden müssen.Jetzt können Sie commonj.work.Work implementieren, einen workmanager von jndi beziehen und die Work-Klasse übermitteln. Der Hauptvorteil ist, dass commonj von anderen Anwendungsservern unterstützt werden kann. Weblogic 9.0+ tut es, geronimo, und leider kein anderer, bis jetzt (afaik). Ihre Anwendung ist jetzt also nur noch ein bisschen portabler. Ich denke, Commonj könnte mit Jboss AS zusammenarbeiten. Sie müssten den Workmanager (und andere Klassen) selbst implementieren, und zwar als Mbean.In der Spring-Javadoc wird mit Bedauern erwähnt, dass es keine offizielle Herstellerunterstützung für commonj gibt. Und ich habe keine Informationen über die Ursprünge und die Zukunft von commonj finden können. Apropos Spring, sie stellen einige sehr nützliche Klassen zur Verfügung, die das obige Verfahren noch weiter vereinfachen: erstellen Sie eine org.springframework.scheduling.commonj.WorkManagerTaskExecutor-Instanz, geben Sie einen jndi-Namen an und übergeben Sie eine beliebige Runnable-Klasse. Sie benötigen nur commonj in Ihrem Build-Pfad, der sich in den Spring-Abhängigkeiten befindet. Wenn Sie mit Websphere 6.1 arbeiten, haben Sie standardmäßig einen WorkManager, der wm/default für den jndi-Lookup verwendet. Beim Lookup wird ein Protokolleintrag erscheinen, der besagt, dass Sie keine Ressourcenreferenz verwendet haben. Dennoch funktioniert alles einwandfrei. Fügen Sie den Ressourcenverweis mit den folgenden Zeilen in Ihre web.xml ein <resource-ref>    <res-ref-name>wm/WorkManager</res-ref-name>    <res-type>commonj.work.WorkManager</res-type>    <res-auth>Container</res-auth>    <res-sharing-scope>Shareable</res-sharing-scope> </resource-ref> Der Deployer muss dies zum Zeitpunkt der Bereitstellung auf den tatsächlichen WorkManager abbilden. Spring fügt java:comp/env zu Ihrem jndi-Namen hinzu, wenn Sie das Flag resourceRef auf true setzen. Sowohl commonj als auch spring unterstützen auch das Scheduling von Jobs. Dies könnte ein sicherer Weg sein als die Verwendung von Quarz, insbesondere wenn Ihre Aufträge Zugriff auf eine Datenbank benötigen. Die Konfiguration des WorkManagers ist eine andere Sache. Ihr Administrator muss wissen, wie viele Threads Sie erwarten. In Websphere können Sie auch festlegen, ob das JAAS-Subjekt des geplanten Threads an den geplanten Thread weitergegeben werden muss. Wenn diese Option deaktiviert ist, hat der geplante Thread keinen Sicherheitskontext. Er ist nicht in der Lage, EJBs oder andere Dienste aufzurufen (es sei denn, diese melden sich selbst an). Die Eigenschaft growable macht das Maximum des Threadpools obsolet und es kann eine beliebige Anzahl von Threads gestartet werden. Das ist in Ordnung, solange genügend Ressourcen vorhanden sind. Es ist wahrscheinlich eine gute Einstellung, um die Anzahl der Threads in bestimmten Situationen (z.B. unter Last) herauszufinden. Sobald Sie diese Zahl ermittelt haben, setzen Sie sie als Maximum für den Threadpool ein und deaktivieren Sie growable. Fazit Es gibt keinen Grund, nackte Threads zu erstellen. Aapache und zwei große Anbieter unterstützen commonj. Bestehende Anwendungen und Frameworks, die in einem j2ee-Container laufen, sollten so angepasst werden, dass sie zumindest versuchen, einen commonj WorkManager zu erhalten, bevor sie selbst Threads erstellen. Spring bietet hierfür eine gute Lösung. Sprechen Sie mit Ihrem Administrator, um die Details des Threadpools zu klären. Empfohlene Lektüre Parallele Verarbeitung in einem J2EE Container Optimierung der geplanten Arbeit mit Work Managern