JSF refresh vs. session scope

Status
Nicht offen für weitere Antworten.

Marsman

Bekanntes Mitglied
Hallo Ihr!

Ich habe mal wieder eine Frage bzgl. JSF und "best practice": Häufig sieht man für Managed Beans folgende Patterns. Ich frage mich dabei, welche Vor- oder Nachteile diese im Vergleich miteinander haben.

Bean im Request-Scope:

Code:
public class RequestBean {

  DataModel data;

  public RequestBean() {
    this.data = loadData();
  }

  public DataModel getData() {
    return this.data;
  }
}

Bean im Session-Scope:

Code:
public class SessionBean {

  DataModel data;

  public SessionBean() {
    reset();
  }

  public DataModel getData() {
    if (data == null) {
      this.data = loadData();
    }
    return this.data;
  }

  public void reset() {
    this.data = null;
  }
}

Ist das einfach nur eine Frage des persönlichen Geschmacks oder gibt es bestimmte Gründe, die eine oder andere Variante vorzuziehen?


Titus
 

Marsman

Bekanntes Mitglied
maki hat gesagt.:
Dir ist der Unterschied zwischen den beiden klar?

Beim Request-Scope wird die Bean mit jedem Request neu instanziert. Also quasi jedes Mal, wenn der Browser die zugehörige Seite anzeigt (deshalb kann das Laden der Daten auch im Konstruktor liegen). Beim Session-Scope hingegen nur einmal zu Beginn der Session, also wenn ein User die Anwendung zum ersten Mal aufruft (deshalb muss das refreshen der Daten anderweitig bewerkstelligt werden).

Ich denke, es gibt je nach Lebensdauer einer Session Unterschiede bzgl. Speicherresourcen im Server. Anderseits aber auch evtl. Probleme mit der Auslastung bei zu vielen Resource-Beans. Ist das richtig und gibt es noch andere Vor- und Nachteile?

Titus
 
M

maki

Gast
IMHO sind deine Gedanken nicht verkehrt, allerdings kann man nicht pauschal beantworten was besser ist, lazy init oder nicht, dazu müsste man mehr wissen.
 

Terminator

Aktives Mitglied
mal theorethisch!


RequestBean:
- Sieht ja so aus, als wenn das immer laden tut, also auch bei nem Postback mit ValidierungsFehler, wenn da load ne DB-Action bedeutet finde ich das ne Verschwendung von Resourcen.
- Ausserdem, falls DB-Aktion, würde der User bei nem Vali-Fehlern auf einmal nen anderen Datenstand vorgesetzt bekommen, da Daten neu von DB abgerufen werden (ausser es wäre selbe connection in gleicher transaction)



SessionBean
- der Construktor ist doch sinnlos oder seh ich da was net?
- Sinn von reset versteh ich irgendwie sowie so net
 
G

Guest

Gast
Terminator hat gesagt.:
ResourceBean: Sieht ja so aus, als wenn das immer laden tut, also auch bei nem Postback mit ValidierungsFehler, wenn da load ne DB-Action bedeutet finde ich das ne Verschwendung von Resourcen.

Es sei denn, es handelt sich z.B. um eine Liste, die bei jeder Anzeige der Seite die aktuellen Daten enthalten soll?


SessionBean:
- der Construktor ist doch sinnlos oder seh ich da was net?
- Sinn von reset versteh ich irgendwie sowie so net

Eigentlich schon. Ich hatte in meinem Beispiel allerdings eine Methode vergessen. Dann wirds evtl. klarer:

Code:
public String edit() {
  // Code zur Parameterübergabe an Edit-Bean.
  reset();
  return "toEditPage";
}

reset() soll in der Bean im Session-Scope eigentlich nur bewerkstelligen, dass beim nächsten Betreten der Seite, die Daten der Liste erneut geladen werden. So z.B. auch beim Übergang zu einer Seite zum Editieren eines Datensatzes.

Ich gebe zu, dass mein Code etwas aus dem Zusammenhang gerissen ist. Ich habe diese Variante im Sun-Forum (siehe hier) gesehen und fand sie recht nice.

Titus
 

KSG9|sebastian

Top Contributor
Ok, jetzt wirds ganz sinnbefreit. Einen Bean im Session-Scope abzulegen aber trotzdem bei jedem Request ein Reset zu fahren?? Was soll dass denn für einen Sinn haben?

Wenn ne Änderung passiert wird die Änderung in die DB geschrieben und der Bean aktualisiert. Die Codesnippets machen imho nur Sinn wenn in die Datenbank auserhalb der Anwendung geschrieben wird UND die Daten die von außen kommen auch wirklich Zeitkritisch zur anzeige kommen müssen.
 
G

Guest

Gast
KSG9|sebastian hat gesagt.:
Ok, jetzt wirds ganz sinnbefreit. Einen Bean im Session-Scope abzulegen aber trotzdem bei jedem Request ein Reset zu fahren??

Nein, nicht bei jedem Request. Nur dann, wenn über eine andere View Daten geändert wurden. :noe:

Im Grunde handelt es sich bei der Application um eine klassische Datenverwaltung. In einer View (1) wird eine Liste der Datensätze angezeigt. Über eine weitere View (2) kann ein einzelner Datensatz hinzugefügt, geändert oder gelöscht werden. Bei der Rückkehr in die View mit der Liste, soll diese neu geladen werden. Und zwar möglichst nur dann, wenn die Änderung tatsächlich durchgeführt wurde.

Je Anzeige gibt es eine Bean. Die Frage ist nun, wie Bean 1 von der durchgeführten Änderung in Bean 2 erfährt, um die Liste neu zu laden?? Und zwar ohne dass Bean 2 auf Bean 1 zugreift. Denn das ganze soll wiederverwendbar sein. View 2 kann also evtl. auch über View 3, 4 oder 5 aufgerufen werden.

Das mit dem allgemeinem reset() habe ich aufgrund der Empörung hier auch wieder entfernt. :oops: Aber wie kann ich das Problem nun lösen?

Titus
 
Status
Nicht offen für weitere Antworten.
Ähnliche Java Themen
  Titel Forum Antworten Datum
M JSP JSP in JSP mit refresh einbinden Web Tier 5
P JSF Ajax refresh nach Linkklick Web Tier 4
J h:selectOneMenu und Page-Refresh Web Tier 3
R JSF und Browser Refresh Web Tier 7
I Gleiche Session von EJB Container in JSF Container verwenden? Web Tier 21
R Session löschen Web Tier 3
J Session ist nach Klick auf Zurück-Button wieder aktiv Web Tier 3
jann Servlet Bei jedem Request wird eine neue Session erstellt. Web Tier 6
J Session Servlet - JavaScript Web Tier 6
M Session closed - und nun? Web Tier 1
F JSF synchronized(session) Frage ? Web Tier 1
F JSF p:selectOneMenu Session Web Tier 10
T JSF Problem wenn Session abgelaufen ist Web Tier 6
Q JSF bei Session-Timeout Weiterleitung auf spezielle Login-Seite Web Tier 15
D JSF Überprüfen der Session ID in JSF und JAVA Web Tier 9
R Servlet Resource laden für SMTP - Session Web Tier 4
B JSF Mojarra 2.1.5: java.lang.IllegalStateException: Cannot create a session after the response has been Web Tier 7
R JSF Session Handling Web Tier 3
X JSP Auslesen der Daten einer Session Web Tier 3
X Managed Bean Scope zwischen Request und Session gesucht Web Tier 6
crashfinger JSP Session verloren bei DNS Servernamen & IE Web Tier 6
C session trackung auf einfacher web-site Web Tier 17
F JSF Session-Kolision Web Tier 3
R Zugriff auf Session direkt auf JSF-Seite Web Tier 2
H JSF Session Initialisierung Web Tier 2
E JSP Browser Tab Session Web Tier 7
F Session Tutorial Web Tier 5
T JSP Session Login - Sicherheit Web Tier 4
J Loginbereich mit Session und Datenbank Web Tier 5
M 2 Cookies in der session (cocoon 2.2) Web Tier 4
F Richtiges Session Management mit Servlets Web Tier 4
P JSP: Liste in Bean über Session aufbauen Web Tier 6
7 Struts+AJAX- Session-Handling? Web Tier 2
B JSF session bean mit worker thread updaten Web Tier 7
J Crash bei session timeout Web Tier 3
M session Speicherort - ID ändern Web Tier 8
V ANFÄNGER : eigene Session Web Tier 3
V DatenbankConnection an Session hängen Web Tier 4
P session.removeAttribute Web Tier 3
K Orientierungslosigkeit: Webservice+Ajax(echo2)+Session-Management Web Tier 4
O struts - Gültigkeit einer Action an Session binden?! Web Tier 4
D JSF: Best Practice "Session invalidate nach Schließen des Browsers"? Web Tier 3
T Unbegrenzte Session Web Tier 14
D tapestry 5 session Web Tier 2
J Struts 2 session ID auslesen? Web Tier 5
M [J2EE] Session-Save Static-Objects? Web Tier 6
S Problem mit Session - Übergabe von Kontext zu Kontext Web Tier 2
F JSF: Beans in Session oder Request? Web Tier 4
H JSF - Bean (scope session) - Verfallsdatum? Web Tier 3
T Problem bei Session-Timeout Web Tier 3
G Session in Servlet Starten und mit JSTL auslesen Web Tier 2
G Servlet - Von Parametern umstellen auf Session Web Tier 8
G jsf session erstellen Web Tier 10
rambozola session attribut in servlets und jsps Web Tier 11
M JSF session.invalidate() klappt nicht Web Tier 3
G Session.invalide() funktioniert nicht richtig Web Tier 2
G JSP mit JS in den page- scope setzen Web Tier 5
ruutaiokwu beanshell scope problem... Web Tier 7
L JSF Request Scope und createValueBinding() Web Tier 1
F richfaches:datascroller mit request-scope Web Tier 6
Y myFaces - Scope und t:saveState Erfahrungen Web Tier 9

Ähnliche Java Themen

Neue Themen


Oben