Hallo,

der ServletContext ist normalerweise der Ort, wo man die Objekte hält, die Application Scope haben, dazu gehören in aller Regel auch teure Objekte, wie Connection Pools. Zur Verbesserung der Antwortzeiten lädt man die meist dann bereits beim Start der Applikation, genauso wie bestimmte Caches; auf altmodische Art über die init Variante eines Autoload Servlets, oder aber über die Context Listener.

Erzeugung von Threads ist normalerweise dem Container überlassen (der das nebenbei bemerkt. besser kann, der verwendet Pools, kümmert sich um Leichen, etc.) und wird nur von diesem ausgeführt, so ganz trivial ist das ja auch nicht, wg. Deadlocks zum Beispiel und eine vollgefressene JVM des Tomcat, oder AppServers ist natürlich der GAU. In einer reinen Java Umgebung ist das unproblematisch, da braucht man keine Hand gestrickten Dienste, sondern regelt das über einen ServletRequest, eine EJB oder einen WebService, letztere beiden wären dann das was man täte und da brauchts keine eigen erzeugten Threads.

Im Mixfall RPG/Java haben wir ja den fatalen Fall, dass wir über den DTAQ Mechanismus ja gerade verhindern wollen, in jedem Job eine JVM zu starten, deswegen scheiden da session Beans leider aus. Am saubersten wäre es m.E. einen relativ schlanken Adapter zu schreiben, der eigentlich nur aus der DTAQ und zurück "übersetzt" und sich ansonsten rein in Java bewegt, dann kann man auch das maximale an Komponenten verwenden. Vielleicht sollten wir hierfür mal ein OpenSource Projekt aufmachen...

mfg

Dieter Bender






Zitat Zitat von RobertPic
Die meisten Argumente kann ich nachvollziehen, aber die Empfehlung


ist mir noch nicht untergekommen - maximal das Dauerläuferthreads in Servlets problematisch sein können. Ansonsten habe durchwegs Anregungen und Beispiele für Threads im Webserver gefunden. Und für was gibt es sonst Listener in der web.xml?

Ansonsten kann ich nur sagen, dass ich hier ein paar 24x7-Dienste laufen habe, der längste davon ein halbes Jahr (inkl. Toolboxtreibern für DataQueue, JDBC).

Das mit dem Overhead ist sicher richtig, deshalb verwende ich das (noch) nicht auf der iSeries - bis zum nächsten Hardwaresprung.

Als "halber" Webprogrammierer habe ich meine Dienste freilich schon um Editor für (Properties + xml), Status und Logabfragen erweitert.

Ob nur Dienste für Tomcat den Aufwand rechtfertigen, ist natürlich (wie Dieter Bender schon anmerkte) nicht gesagt.

In meiner Umgebung (Win/Linux/iSeries + fremde + eigene Webanwendungen) war der Umstieg auf Tomcat ein leichtes.

PS. Hier mal mein aktuelles Javaprojekt (Beta), welches ich auch mal herzeigen kann:

http://odtemp.ath.cx/OdKatalog/tree.zul#gr_0
(der AS/400-Teil ist von außen aber nicht erreichbar)