wir haben in letzter Zeit regelmäßig das Problem, das unsere Datenbank nicht mehr erreichbar ist. Es wird vermutete das einfach zu viele Datenbanksessions existieren.
Wir haben eine Oracle 11g Datenbank uns nutzen Hibernate 3.2.5. .
Jetzt stellt sich mir die Frage ob es eine Möglichkeit gibt, zu gucken ob offene Sessions existieren und wie lange diese inaktiv “rumliegen”?
Ich hab jetzt zumindest schonmal raus gefunden, das man sich aus der Sessionfactory die Statistik auslesen kann und dort zumindest sieht, wieviel geöffnet und geschlossen wurden.
System.out.println("geöffnete Sessions: "+factory.getStatistics().getSessionOpenCount());
System.out.println("geschlossene Sessions: "+factory.getStatistics().getSessionCloseCount());```
Wenn ich nur ein wenig rumgeklickt habe, bekomme ich folgenden Output:
geöffnete Sessions: 19
geschlossene Sessions: 13
Also habe ich jetzt schon 6 offene Sessions rumliegen, das bestätigt also die Vermutung. Aber wie kann ich jetzt die noch offenen Sessions schließen?
Oder kann man den Datenbanksessions auch einen Timeout mitgeben, ähnlich wie bei WebSessions?
die Suchen geben nichts her, und so ein allgemeines Thema wäre sicher bekannt,
da kann man auf die naheliegende allgemeingültige Alternative umschwenken, die bei den Suchergebnissen auch ständig vorkommt:
in den Prozess eingreifen und gewisse Kontrolle übernehmen,
frage nicht simpel aus der Luft bei SessionFactory oder wo auch immer an,
sondern stecke diese elementar wichtigen Befehle in eine eigene Manager-Klasse,
das ist allein zum Loggen usw. wichtig, bietet hinsichtlich Session aber auch alle Möglichkeiten,
Einfügen in eine Liste, Versehen mit zusätzlichen Daten wie Timeout (ob sich Verwender daran hält ist andere Frage),
Thread der alle durchgeht und schließt usw.,
Ausgabe von Statistiken falls es SessionFactoryUtil & Co. zufällig nicht gäbe
usw.
genauso wie man Client-Sockets eines Servers unter Kontrolle haben sollte, Zugriffe auf Files an zentraler Stelle, WebSessions, zumindest anmelden usw.,
das bietet sich immer an
edit:
benötigt natürlich Zugriff auf sämtlichen Code und evtl. gravierend zu bezeichnende Eingriffe,
außerdem für die Zukunft Disziplin der weiteren Verwendung,
aber kann man ja auch regelmäßig prüfen, weitere Codestellen bei Bedarf (neue Engpässe) umstellen
@SlaterB Idee ergänzend möchte ich auf die Interceptors und Listener im JPA-Framework hinweisen mit denen du relativ weit rein schauen kannst was passiert ohne bestehenden Code ändern zu müssen.
danke erstmal für die Ansätze. So wie es aussieht muss ich wohl generell mein SessionManagement nochmal überarbeiten.
Aktuell mach ich jetzt für jeden Zugriff eine Session auf und schließe sie wieder, sobald ich fertig bin. Das ist zwar nicht besonders effizient, aber sollte zumindest unser akutes Problem verhindern.