Java Application Server in einem ungesunden Zustand

[masterjj]

Hallo ,

Ich suche nach Szenarien, die einen Server in einen ungesunden Zustand bringen können. Habt ihr vielleicht Ideen?

Ein mögliches Szenario könnte vielleicht sein, wenn man hängende Threads hat, d.h ein Thread A wartet auf einen Wert von Thread B, und dieser auf einen Wert von Thread A. Also ein möglicher Deadlock, fallen euch vielleicht noch andere Szenarien ein???


Nur her damit, würde mir sehr viel weiterhelfen.


LG, janni

[Alwin Ibba]

System.exit(0);

[masterjj]

System.exit(0);

Stimmt ,daran habe ich gar nicht gedacht!! danke , noch weitere?

[Alwin Ibba]

Endlosschleife, Transaction deadlock

[masterjj]

Endlosschleife, Transaction deadlock

Ja Endlosschleife ist mir heuet auch noch eingefallen, interessant klingt der "Transaction deadlock". Meinst du damit DB-Transaktionen? Um die muss sich doch eigentlich die DB kümmern, erreicht die überhaupt die schicht des Application Servers? Vorstellbar wäre natürlich, dass im Falle eines DB-transaction deadlock die DB dieses Fall in Form einer Exception an den Applicationsserver weitergibt.

Oder meinst du eher Deadlocks, die du Threads verursacht werden, weil im Server laufen ja wirklich unzählige Threads, da könnte ich mir vorstellen, dass ein Thread A auf einen Wert eines anderen wartet und dieser Thread B wiederum auf einen Wert von Thread A , um weiterarbeiten zu können.

[Alwin Ibba]

Transaktionen werden doch von der Applikation gestartet und beendet. Wenn eine Transaktion hängt dann hängt damit automatisch die Anwendung im Server. Abgesehen davon besitzt ein Applikationsserver einen Transaktionsmanager der u.a. mehrere Einzeltransaktionen zu einer globalen Transaktion zusammenfassen kann. Diese globale Transaktion kann auch blockieren. Normalerweise gibt es dafür einen Transactiontimeout, der aber auch beliebig hoch/niedrig konfiguriert sein kann.

In J2EE-Anwendungen wird selten mit komplexen Multithread-Problemen hantiert, das überläßt man dem Server. Natürlich kann es dabei im Fehlerfall auch zu deadlocks kommen.

[masterjj]

Hi, also ich verstehe das mit der Transaktion noch nciht ganz genau. Du sagst, Transaktionen werden von der Applikation gestartet und beendet. Ich versuche mir das gerade am Beispiiel von DB-transaktionen klar zu machen. Also von ich z.b in einer Java applikation mit Datenbankzugriffen arbeite dort starte ich ja INSERT, UPDATE und was weiss ich sonst noch für SQL-befehle. Soweit ich weiss ist die default-einstellung "autocommit=true" d.h jeder SQL-befehl wird als Transaktion aufgefasst , mit Autocommit=false ist es möglich mehre SQL-befehle in eine Transaktion zu bündeln. Was ich nciht genau verstehe ist immo , wo die Transaktion genau gestartet wird. Weil die Applikation an sich besitzt ja keinen Transaktionmanager etc. Er verschickt und erhält. Das Transaktionmanagement fängt dann auf DB-serverseite an, d.h dort wird dann Transaktion gestartet und beendet oder?

Der Container eines Applikationserver kann z.b das Transactionmanagemet übernehmen. Was in Java EE 5 durch Annotation steuerbar ist.

[Alwin Ibba]

Die Applikation besitzt keinen Transaktionsmanager aber der App-Server besitzt einen. Diesen kann man benutzen (dann wird die Transaktion automatisch durch den App-Server oder explizit die Applikation gestartet) oder auch nicht. Wenn nicht arbeitet man eben mit entsprechenden APIs zum Zugriff auf die transaktionale Quelle (z.b. JDBC oder JMS, DBs sind nicht die einzigen Systeme, die Transaktionen benötigen). In diesem Fall startet ebenfalls die Applikation die Transaktion, bei JDBC eben automatisch/implizit durch Absetzen eines statements. Natürlich läuft die eigentliche Transaktion auf der DB, aber wenn diese hängt, hängt natürlich die Appliaktion, da sie ja auf das Ende der Transaktion wartet, darum gings ja.

Der Container eines Applikationserver kann z.b das Transactionmanagemet übernehmen. Was in Java EE 5 durch Annotation steuerbar ist.

Richtig. Oder durch XML-Files wie in J2EE 1.4, 1.3 etc. http://java.sun.com/javaee/5/docs/tu...doc/bncih.html

[masterjj]

jupp danke dir , das war sehr hilf-und lehrreich! Gruss Jan

[Stefan Gawlick]

Hallo Jan,

auch zu viele / zu große Objekte, die in der Session ge-cached werden, können zu Problemen führen. Selbst ohne Out of Memory kann es zu massiven Garbage Collector-Aktivitäten kommen, welche die eigentliche Arbeit blockieren.

[masterjj]

Hallo Jan,

auch zu viele / zu große Objekte, die in der Session ge-cached werden, können zu Problemen führen. Selbst ohne Out of Memory kann es zu massiven Garbage Collector-Aktivitäten kommen, welche die eigentliche Arbeit blockieren.

Hallo Stefan,

ah , das ist auch ein interessanter Punkt. Kannst du das vielleicht mit der Session und dem Cache genauer erklären an einem Beispiel vielleicht? Also soweit ich das verstanden habe , ist der Cache ja dazu da, um eventuelle gleiche oder ähnliche Anfragen schneller verarbeiten zu können, in dem man sich die Werte aus dem Cache holt oder diese geholt werden. Bei Servlets kenne ich dieses HTTPSession und bei EJB eben die SessionBeans (Stateless/ stateful). Wenn jetzt also ein Client eine Anfrage stellt und diese durch das Servlet verarbeitet wird, kann man ja eventuelle Werte in so einer HTTPSession abspeichern. Fängt hier dann der Cache schon an zu arbeiten? Gibt es bei Applikationsservern nicht einen Monitoring-mechanism , der sowas verhindern kann, dass zu grosse Objekte abgespeichert werden können? Ich denke da an Mbeans(JMX) etc.

Gruss Jan