Frage zu PreparedStatement/ResultSet

[Red Baron]

Hallo, ich habe eine Applikation, die mit Hilfe des BeaWeblogic Server läuft. Ich habe mehrere Methoden, die Daten aus einer Oracle 9 Datenbank lesen. Dazu erstelle ich ein PreparedStatement und erhalte beim Ausführen der Anfrage ein ResultSet zurück.
In letzter Zeit habe ich oft Systemabstürze. Im Bea Log ist immer von Stuck Thread zu lesen. Die Spur verliert sich beim Zugriff auf das ResultSet. Nun zu meinen Fragen:

1. Wie funktioniert ein ResultSet? Ich habe gehört, dass der Oracle-Treiber selbst entscheidet, ob er bei einem ResultSet die ganzen Daten auf einmal zurück liefert oder immer beim Aufruf des ResultSets den entsprechenden Datensatz erst liest.

2. Bei Fehlern treten ja SQL-Exceptions auf. Ich erhalte allerdings nie SQL-Exceptions (ja, ich catche SQLExceptions). Gibt es bekannte Fehler in denen beim Zusammenhang PreparedStatement-ResultSet-Oracle Datenbank keine SQLExceptions geworden werden und man quasi im Dunkeln sitzt?

3. Falls einem dieses Problem bekannt vorkommt. Gibt es eine Lösung oder einen Tipp, um dieses Problem zu lösen?

Danke für Eure Hilfe.

 

[DerEisteeTrinker]

zu 1.

Ist doch völlig egal. Hauptsache du hast deine Daten und kannst damit arbeiten. Bei ner Kuh möcht ich auch aus Gras Milch haben, was die da für krankes Zeug im Inneren macht, möcht ich garnicht wissen

zu 2.

Bist du dir sicher, dass da eine SQLException geworfen wird? Vllt hast du deine Statements so gewählt, dass du keine Fehler aus der Datenbank bekommst. Schau auch nach, ob vllt eine Methode die Exception verschluckt und somit die Exception nicht da ankommt, wo du es vllt erwartest.

zu 3.

I don't know. Isch ALI isch nix schuld

 

[maki]

2. Bei Fehlern treten ja SQL-Exceptions auf. Ich erhalte allerdings nie SQL-Exceptions (ja, ich catche SQLExceptions). Gibt es bekannte Fehler in denen beim Zusammenhang PreparedStatement-ResultSet-Oracle Datenbank keine SQLExceptions geworden werden und man quasi im Dunkeln sitzt?

Stuck Thread ist doch sehr aussagekräftig, d.h. dass ein thread nicht innerhalb des festgelegten Timeouts "fertig" geworden ist und vom Server gestoppt wird.
Da bekommst du logischerweise keine SQLExceptoin...

 

[DerEisteeTrinker]

also ich hab beruflich mit "größeren" Anfragen zu tun, die auch aus dem TimeOut laufen und da wird trotzdem ne Exception geworfen. Wenn da so 50 Mio. Datensätze verarbeitet werden wollen, dann musst du das stückeln und wenn das nicht innerhalb der Zeit passiert, verlassen wir uns sogar auf die Exception und die hat uns noch nie enttäuscht

 

[maki]

also ich hab beruflich mit "größeren" Anfragen zu tun, die auch aus dem TimeOut laufen und da wird trotzdem ne Exception geworfen. Wenn da so 50 Mio. Datensätze verarbeitet werden wollen, dann musst du das stückeln und wenn das nicht innerhalb der Zeit passiert, verlassen wir uns sogar auf die Exception und die hat uns noch nie enttäuscht

Klar wird eine Exception geworfen, aber in diesem Fall von WebLogic, nicht von der DB oder dem JDBC Treiber

Auf welchem Server laufen denn eure Apps? Auch WebLogic?

 

[DerEisteeTrinker]

bei uns ist es WAS :bae:

 

[maki]

bei uns ist es WAS :bae:

Du meinst wohl WebSphere

Dir ist schon klar dass der WebLogic selber nochmals einen Timeout definiert für Threads? Wenn dieser überschritten wird, gibt es eben keine SQlException, denn weder der JDBC Treiber noch die DB hatten ein Problem, sondern schlicht dass der Thread länger gelaufen ist als von WebLogic erlaubt -> keine SqlException

 

[DerEisteeTrinker]

ist ja schon gut, ich gebe auf und ergebe mich

 

[maki]

Musst du doch gar nicht

Mal schauen wie lange es dauert bis der TS fragt wo man den Timeout erhöhen kann

 

[DerEisteeTrinker]

timeout garnicht :bae:

sondern wenn du schon mit servern arbeitest, dann mach das nach möglichkeit asynchron als MessageDrivenBean

 

[maki]

timeout garnicht :bae:

sondern wenn du schon mit servern arbeitest, dann mach das nach möglichkeit asynchron als MessageDrivenBean

Solange wir uns einig sind das wir von Threads sprechen die auf dem Server laufen und dann den Timeout überschreiten... dann wird nämlich klar dass asychrone Verarbeitung auch nix nutzt in diesem Falle

 

[DerEisteeTrinker]

na ich schätze mal, dass der der dieses thread geöffnet hat, nicht nur eine abarbeitung hat, sondern mehrere und die als ganzes bestimmt zu lange brauchen.

MessageDrivenBeans sind Threads von Stand-Alone Anwendung auf Servern. Nur hast du über diese Beans keine Gewalt. Du gibst die Abarbeitung vor und dann geht es ab mit den Pferden. Du kannst dann lauter Messages an den Server schicken, der macht so eine Bean draus und schon arbeitet er drauf los. Zumindest beim WAS kannst du auch sagen, wieviele gleichzeitig da laufen. Bei uns sind es bis zu 20 Beans auf einmal

 

[maki]

Er hat diesen Thread nicht manuell selber gestartet, sondern der Server.
Auf JEE Server ist es nämlich verboten eigene Threads manuell zu starten

Das Problem ist wie gesagt nicht die EJB, ob MessageDriven oder nicht ist egal, sondern schlicht dass der Thread zu lange läuft... -> Timeout

 

[DerEisteeTrinker]

mein threa dbezog sich auf das thema hier, nicht auf java. mensch maki, du scheinst ja echt verliebt zu sein in java :lol::lol::lol::lol::lol::lol::lol::lol::lol:

 

[maki]

mein threa dbezog sich auf das thema hier, nicht auf java. mensch maki, du scheinst ja echt verliebt zu sein in java :lol::lol::lol::lol::lol::lol::lol::lol::lol:

Das Thema hier: Probleme mit einem Stuck Thread auf einem WebLogic Server, das hier ist ein Java Forum.

Wovon sprichst du?
MessageDrivenBeans... JEE, gehört auch zu Java.

Irgendwie glaube ich hier gibt es ein Verständnisproblem... auf deiner Seite.

Aber sei's drum...

 

[DerEisteeTrinker]

ich habe das wort "thread" nicht als Begriff in Java gemeint eben, sondern im Sinne von Thema in einem Forum

 

[maki]

Ahhh...

na ich schätze mal, dass der der dieses thread geöffnet hat, nicht nur eine abarbeitung hat, sondern mehrere und die als ganzes bestimmt zu lange brauchen.

MessageDrivenBeans sind Threads von Stand-Alone Anwendung auf Servern.

.. jetzt verstehe ich was du meinst, nix für ungut