Hallo, wie kann ich Klassen dauerhaft im Speicher halten für JSP-Seiten?
Ich möchte z.B. einen Connection-Pool offenhalten. Nun kenne ich eine Lösung, in der ich auf meinen JSP’s ein Bean mit Session-Scope benutze, dass wiederum statische Members hat, die beim erstmaligen Aufruf einer JSP initialisiert werden und dann setze ich einfach ein boolean smIsInitialized = true oder so.
Aber is das eine gute Lösung? Auch möglich wäre vermutlich ein anderes Bean in der JSP anzugeben mit Application-Scope, aber das erscheint mir auch nicht so toll, vor allem geht es die JSP eigentlich nix an, was an Anwendungslogik dahinter steckt.
Wie macht man denn sowas vernünftig?
MfG Bruno
Ich würde es auch über Beans machen. Allerdings denke ich wirst du um den Application-Scope nicht herumkommen, nur innerhalb einer Session macht der Connection-Pool nicht soviel Sinn, oder?
Grüße, Robert
Ich würde es auch über Beans machen. Allerdings denke ich
wirst du um den Application-Scope nicht herumkommen, nur
innerhalb einer Session macht der Connection-Pool nicht soviel
Sinn, oder?
Das ist klar… ich finde es nur irgendwie blöd, zwei Beans innerhalb meiner JSP zu verwenden. Wenn ich z.b. nur einnen Datensatz lesen möchte, könnte ich in meiner Session-Bean eine Methode wie holeDatensatz() implementieren. Für die JSP ist es ja total egal woher die Daten kommen und wie dies funktioniert. Ich glaube da gefällt mir die Lösung mit den statischen Members (schonmal in einem Programm gesehen) irgendwie schon besser, da is die Anwendungslogik mehr versteckt.
Gibt es eigentlich eine Möglichkeit eine Application-Bean zu killen ohne die ServletEngine zu stoppen?
Hallo Bruno!
Hmmm, ich glaube ich verstehe erst jetzt was du meinst. Nur, was nutzt dir der statische Member alleine, du mußt ja die Verbindungen speichern, die Verbindungen müssen geöffnet werden, du brauchst Zugriffsmethoden auf die Verbindungen etc.
Würdest du das alles mit statischen Membern/Methoden machen?
Gibt es eigentlich eine Möglichkeit eine Application-Bean zu
killen ohne die ServletEngine zu stoppen?
Ist mir noch nie untergekommen.
Grüße, Robert
OK ich erklärs nochmal genauer.
Ich brauche auf jeden Fall ein Bean mit Session Scope weil ich Session-spezifische Daten speichern möchte.
Die Lösung mit den statischen Members sieht so aus (und funktioniert auch… allerdings dachte ich es gibt evtl. schönere):
In meiner Bean (die ich per Session Scope instanziiere) gibt es z.b. diese Member
private static ConnectionPool smConnectionPool = null;
private static boolean smIsInitialized = false;
Nun haue ich in den Konstruktor der Bean folgendes rein
if (!smIsInitialized)
{
smConnectionPool = new ConnectionPool();
smIsInitialized = true;
}
Jetzt kann ich in meiner Session-Bean z.b. eine Methode schreiben in der Art
public String holeWertAusDatenbank()
{
Connection conn = smConnectionPool.getConnection();
...
conn.close();
}
und so den gemeinsamen Pool verwenden, obwohl ich verschiedene Instanzen der Bean habe…
ich weiss aber ned ob diese vergewaltigung von statischen members programmiertechnisch gut ist?
Hallo Bruno!
Technisch fällt mir nichts ein was dagegen spricht, ist denke ich Design-Frage und darüber könnte man ewig streiten. 
Das einzige was mir an deinem Beispiel-Code aufgefallen ist, dass du die Connection schließt, eigentlich mußt du sie ja wieder zurückgeben. :o)
Grüße, Robert
Hallo Bruno!
Nochwas ist mir eingefallen, das mit der Variable zur Initialisierung kannst du dir sparen, mach einfach:
class SessionBean
{
public static ConnectionHandler m\_oConnHandler = new ConnectionHandler();
}
Dann wird der ConnectionHandler gleich am Anfang (frag mich nicht wann genau am Anfang, vermutlich wenn er die Klasse zum ersten Mal lädt) erzeugt.
Grüße, Robert
Technisch fällt mir nichts ein was dagegen spricht, ist denke
ich Design-Frage und darüber könnte man ewig streiten.
Gut Solche Streits interessieren mich ned sonderlich, solange es zuverlässig ist…
Das einzige was mir an deinem Beispiel-Code aufgefallen ist,
dass du die Connection schließt, eigentlich mußt du sie ja
wieder zurückgeben. :o)
hehe das war nue ein Pseudecode … ich hätte ja auch ein return noch danach haben müssen weil ich ja gesagt habe die Funktion gibt einen String zurück 
Habe aber neulich tatsächlich einen Connection Pool gesehen, die das Interface Connection so abgewandelt haben, dass es eben zurückgibt bei close()
class SessionBean
{
public static ConnectionHandler m_oConnHandler = new
ConnectionHandler();
}
Dann wird der ConnectionHandler gleich am Anfang (frag mich
nicht wann genau am Anfang, vermutlich wenn er die Klasse zum
ersten Mal lädt) erzeugt.
Echt? aha das muss ich mal probieren… hab ich eh noch nie verstanden was das bedeutet wenn ich gleich bei der Initialisierung gleich ein new oder so reinhaue statt im Konstruktor…
hehe das war nue ein Pseudecode … ich hätte ja auch ein
return noch danach haben müssen weil ich ja gesagt habe die
Funktion gibt einen String zurück Habe aber neulich
tatsächlich einen Connection Pool gesehen, die das Interface
Connection so abgewandelt haben, dass es eben zurückgibt bei
close()
Das ist eine interessante Variante. So könnte man das praktisch als JDBC-Treiber implementieren und für bestehende Anwendungen damit transparent machen.
Schau mal auf http://developer.java.sun.com/developer/onlineTraini… da wird sowas diskutiert.
Eventuell finden sich irgendwo auch so was schon vorgefertigt.
Außerdem ist Connection Pooling in JDBC seit 2.0 enthalten, ich glaube aber nicht zwingend vorgeschrieben, informier dich mal ob dein Treiber das vielleicht nicht eh von selbst tut.
Grüße, Robert
Echt? aha das muss ich mal probieren… hab ich eh noch nie
verstanden was das bedeutet wenn ich gleich bei der
Initialisierung gleich ein new oder so reinhaue statt im
Konstruktor…
Bei nicht static Membern macht er es AFAIK beim Erzeugen des Objekts, noch bevor er den Konstruktor aufruft, bei static Membern bin ich mir wie gesagt auch nicht so sicher, aber ich habs ausprobiert, du kannst denke ich davon ausgehen, dass das Objekt erzeugt ist bevor du zum ersten Mal zugreifst.
Grüße, Robert
Schau mal auf
http://developer.java.sun.com/developer/onlineTraini…
da wird sowas diskutiert.
Ich Idiot, ich suche grade ewig den Link, auf dem ich das gesehen habe und als ich ihn endlich habe lande ich auf genau der Seite von dir
Außerdem ist Connection Pooling in JDBC seit 2.0 enthalten,
ich glaube aber nicht zwingend vorgeschrieben, informier dich
mal ob dein Treiber das vielleicht nicht eh von selbst tut.
Tut meiner ned… aber mal schauen vielleicht gibts auch andere… ich suche einen mySQL-Treiber