Servlet destroy

[MQue]

Hallo,

hab mal wieder eine (hoffentlich noch nicht nervige) Frage zu einem Servlet,
Wenn ich eine erste Anfrage vom Client an der Server (das Servlet) stelle, dann wird bei mir in der Methode doPost(...) eine Session erzeugt und der Client mit der IP- Adresse und dem Port über Hibernate in eine Tabelle der Datenbank eingetragen.

Wenn am Client der Browser geschlossen wird, dann soll die IP-Adresse und der Port dieses Clients wieder ausgetragen werden.
Meine Frage wäre jetzt, kann ich das im Servlet- Lifecycle realisieren (also in der Methode destroy()) oder kann man das beim WebContainer Tomcat nicht sagen, wann (bzw. ob überhaupt) die destroy- Methode aufgerufen wird? Ist es ok, wenn ich das Austragen in der destroy- Methode mache?

lg

 

[maki]

Wenn am Client der Browser geschlossen wird, dann soll die IP-Adresse und der Port dieses Clients wieder ausgetragen werden.

Das bekommt der Server doch gar nicht mit.
Da bleibt nur der Session Timeout, kennst du schon das Interface HttpSessionListener?

Wozu überhaupt in eine DB speichern wenn es sowieso wieder gelöscht werden soll?
Reicht den keine Map, die von einem Filter verwaltet wird?

Meine Frage wäre jetzt, kann ich das im Servlet- Lifecycle realisieren (also in der Methode destroy()) oder kann man das beim WebContainer Tomcat nicht sagen, wann (bzw. ob überhaupt) die destroy- Methode aufgerufen wird? Ist es ok, wenn ich das Austragen in der destroy- Methode mache?

Die ist anscheinend nicht klar wozu die destroy Methode da ist, oder??

Wieso nicht mal die Doku lesen? Die Servlet Spek. lesen tut nicht weh und hilft dem Veständnis, verringert auch die Verwirrtheit

 

[MQue]

Hab ich gemacht, sollt ich vielleicht öfter reinschauen

When the servlet container determines that a servlet should be removed from
service, it calls the destroy method of the Servlet interface to allow the servlet to
release any resources it is using and save any persistent state. For example, the
container may do this when it wants to conserve memory resources, or when it is
being shut down.

lg

 

[FArt]

Der Lifecycle gilt für eine Servletinstanz, nicht für die Sessions. Die Sessions haben auch einen Lifecycle, die du über Listener mitbekommen kannst.

Schau mal in die Servletspec: SRV 10.2.1

Die Spec ist überhaupt zu empfehlen ;-)

[EDIT]
Außerdem bist du im falschen Gehege. Du hättest zum Web Tier gehört ;-)

 

[maki]

Hab ich gemacht, sollt ich vielleicht öfter reinschauen

Wie wäre es mit durchlesen anstatt reinzuschauen? Schaden würde es dir nicht.

[EDIT]
Außerdem bist du im falschen Gehege. Du hättest zum Web Tier gehört

Erledigt.

 

[MQue]

Wie wäre es mit durchlesen anstatt reinzuschauen? Schaden würde es dir nicht.

Da hast Du schon recht auf der einen Seite und ich hab auch nichts gegens lesen und nachschlagen nur bei uns ist alles sehr knapp bemessen, ich bin der einzige Java- Programmieren und muss mir daher alles selber beibringen. Gegen das hab ich auch noch nichts aber es fehlen halt manchmal auch Diskusionen (z.B.: war mit neu, dass es eine Servlet- Spezifikation gibt).
Ich werde versuchen bevor ich einen neuen Thread aufmache, (noch) mehr zu recherchieren, wobei ich sagen muss, dass ich auf Deine Antworten nicht verzichten möchte, sind immer sehr hilfreich.
lg

 

[FArt]

Da hast Du schon recht auf der einen Seite und ich hab auch nichts gegens lesen und nachschlagen nur bei uns ist alles sehr knapp bemessen, ich bin der einzige Java- Programmieren und muss mir daher alles selber beibringen. Gegen das hab ich auch noch nichts aber es fehlen halt manchmal auch Diskusionen (z.B.: war mit neu, dass es eine Servlet- Spezifikation gibt).
Ich werde versuchen bevor ich einen neuen Thread aufmache, (noch) mehr zu recherchieren, wobei ich sagen muss, dass ich auf Deine Antworten nicht verzichten möchte, sind immer sehr hilfreich.
lg

Müde Ausrede ;-)

Ohne die Theorie zu kennen (und die Spec) wirst du kein sauberes Design und keine saubere Implementierung zustande bringen. Mit sauber meine ich, dass es dir plötzlich in der Produktion um die Ohren fliegen könnte, weil sich der Container anders verhält oder die Infrastruktur leicht unterschiedlich ist.
Zusammengerechnet sind die Probleme, die man sich dadurch einhandelt, teurer und zeitaufwendiger, als es gleich richtig zu machen.

 

[maki]

Zusammengerechnet sind die Probleme, die man sich dadurch einhandelt, teurer und zeitaufwendiger, als es gleich richtig zu machen.

Sehe ich genauso, warum im trüben Fischen wenn man auch sehen könnte was los ist?
Fand die Servlet Spec. immer gut als Bettlektüre.

 

[byte]

Du könntest per JavaScript aufs Verlassen der Seite horchen und dann einen AJAX Call machen.

 

[MQue]

Sehe ich genauso, warum im trüben Fischen wenn man auch sehen könnte was los ist?
Fand die Servlet Spec. immer gut als Bettlektüre.

Da liegen schon 700 Seiten Spring und 400 Seiten Java Concurrency, es ist also wirklich nicht Faulheit, aber ein bisschen Zeit brauch ich no0ch, bis sich das Wasser aufklarrt.
lg

 

[Noctarius]

Du könntest per JavaScript aufs Verlassen der Seite horchen und dann einen AJAX Call machen.

Außer bei Opera z.B. der das Event onBeforeUnload nicht kennt und bei onUnload könnte die Zeit zu kurz sein um den Ajax Request sauber zu feuern.

Da liegen schon 700 Seiten Spring und 400 Seiten Java Concurrency, es ist also wirklich nicht Faulheit, aber ein bisschen Zeit brauch ich no0ch, bis sich das Wasser aufklarrt.
lg

Um Spring im Bereich Servlet zu verstehen sollte man die Servlet Spec kennen, sonst kommt da nie was bei rum. Auch erst zu sagen "hab schon mal reingeschaut" und dann zu sagen "die ist mir neu" erstaunt mich auch etwas.

Abgesehen davon weiß ich nicht ob man sich beim ersten Projekt so extrem mit Concurrency auseinander setzen sollte, dass man das Buch braucht.
Versuch doch erstmal möglichst stateless zu arbeiten.

 

[MQue]

Außer bei Opera z.B. der das Event onBeforeUnload nicht kennt und bei onUnload könnte die Zeit zu kurz sein um den Ajax Request sauber zu feuern.



Um Spring im Bereich Servlet zu verstehen sollte man die Servlet Spec kennen, sonst kommt da nie was bei rum. Auch erst zu sagen "hab schon mal reingeschaut" und dann zu sagen "die ist mir neu" erstaunt mich auch etwas.

Abgesehen davon weiß ich nicht ob man sich beim ersten Projekt so extrem mit Concurrency auseinander setzen sollte, dass man das Buch braucht.
Versuch doch erstmal möglichst stateless zu arbeiten.

Ein kleiner Verteidigungsversuch meinerseits, nachdem maki geschrieben hat, dass ich die Servlet- Spezi. lesen soll, hab ich "reingeschaut",

JavaConcurrency lese ich nicht wegen dem Web- Projekt, bei dem ich gerade drann bin sondern wegen dem Vorprojekt, bei dem ich Threads des öfteren benötigt habe.

lg